Re: [bitcoin-dev] BitVM: Compute Anything on Bitcoin

[Russell O'Connor via bitcoin-dev]

While I haven't looked at the BitVM in detail, I would like to mention that
Simplicity's core language (excluding introspection primitives) has the
same expressivity as Boolean circuits.

A few years ago I did some experiments to compile Simplicity expressions to
a system of polynomial constraints (R1CS).  The experiments were
successful. For instance, I was able to compile our Sha256 compression
function specification written in Simplicity to a set of approximately
128,000 constraints.  Under this "circuit" interpretation, Simplicity types
represent cables, which are a bundle of wires equal to the 'bit size' of
the given type. The 'case' combinator ends up being the only "active"
component (implementing a demux).  The 'injr' and 'injr' combinators output
some fixed Boolean values. The rest of the combinations end up only
connecting, bundling and unbundling wires, and contribute no constraints at
all.

While my previous experiment was generating constraints, it is clear to me
that a similar interpretation could instead generate logic gates, and I
would expect the same order of magnitude in the number of gates generated
as the number of constraints generated above.  Thus Simplicity could be
used as a source of ready made expressions to generate useful circuits for
the BitVM, should someone be interested in pursuing this angle.

On Mon, Oct 9, 2023 at 10:05 AM Robin Linus via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Abstract. BitVM is a computing paradigm to express Turing-complete Bitcoin
> contracts. This requires no changes to the network’s consensus rules.
> Rather than executing computations on Bitcoin, they are merely verified,
> similarly to optimistic rollups. A prover makes a claim that a given
> function evaluates for some particular inputs to some specific output. If
> that claim is false, then the verifier can perform a succinct fraud proof
> and punish the prover. Using this mechanism, any computable function can be
> verified on Bitcoin. Committing to a large program in a Taproot address
> requires significant amounts of off-chain computation and communication,
> however the resulting on-chain footprint is minimal. As long as both
> parties collaborate, they can perform arbitrarily complex, stateful
> off-chain computation, without leaving any trace in the chain. On-chain
> execution is required only in case of a dispute.
>
> https://bitvm.org/bitvm.pdf
> ___
> 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] Concern about "Inscriptions"

[Russell O'Connor via bitcoin-dev]

It's been said before, but I'll say it again:

If we ban "arbitrary data", however you want to define it, then actors will
simply respond by encoding their data within sets of public keys.  Public
key data is indistinguishable from random data, and, unless we are willing
to pad the blockchain with proof of knowledge of secret keys, there will be
no way to tell a priori whether a given public key is really a public key
or whether it is encoding an inscription or some other data.

When certain governments try to censor certain internet protocols, users
respond by tunnelling their protocol through something that appears to be
innocent HTTPS (see Tor bridge nodes).  This works because, after a
handshake, the remaining HTTPS stream, like public keys, is
indistinguishable from random data, and can be used as a communications
channel for arbitrary data.  If we attempt to ban "arbitrary data", those
users will simply respond by "tunneling" their data over innocent-looking
public key data instead.

Please correct me if I'm wrong, but I believe Counterparty has, in the
past, encoded their data within public key data, so this concern is not
hypothetical.

On Sat, Aug 19, 2023 at 10:29 AM Chris Martl via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> It is already more than a half year since the probably mayor Bitcoin
> script exploit started.
>
>
> These exploits are nothing new in the Bitcoin history and mostly are due
> to the loose flexibility of the system in regards of processing
> predicatives (Bitcoin script). The very first mayor bug; if you wish,
> vulnerability, was the CVE-2010-5141, which still engages us without end
> even after 14 years.
>
>
> Subsequent Bitcoin historical events let to build more “improvements” upon
> this wobbly basis exposing even more ground for exploits.
>
>
> As long as this loose flexibility is not modified in a way its exposure
> for exploits is eliminated remains nothing else than to pursue other
> strategies; and ones which are compatible with the current status quo and
> furthermore, with a permission-less system.
>
>
> Here a strategy proposal:
>
>
> Let’s name it: #Ordisrespector and #Ordislow.
>
>
> Why #Ordisrespector and #Ordislow are compatible with a permission-less
> system.
>
>
> #Ordisrespector gives the option to a regular Bitcoin node operator to
> opt-in or not to a self-defense of his/her storage property (and thus of
> his/her integrity); by giving a signal of dissatisfaction with the current
> affairs of aggression via insertion of arbitrary data into the witness
> structure. This dissatisfaction signal is manifested by not taking into the
> mempool and relaying transactions with inserted arbitrary data in the
> witness structure.
>
>
> #Ordislow gives the option to a regular Bitcoin node operator to opt-in or
> not to a self-defense of his/her storage property (and thus of his/her
> integrity); by increasing the coercion cost of mining-entities relative to
> the cooperation cost of mining-entities due to the current affairs of
> aggression via insertion of arbitrary data into the witness structure. This
> coercion cost increment is manifested by not propagating a found block,
> unless a configurable or maximum delay has elapsed, which contains at least
> a transaction with inserted arbitrary data in the witness structure.
>
>
> Chris___
> 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] Codex32

[Russell O'Connor via bitcoin-dev]

One more thing (Again apologies. This idea of doing partial verification is
novel to me, and I see now that I should have just waited to give a
consolidated reply).

Focusing in on the example of performing 2 character quick checks.  There
are 7 different ways of building the table used in this quick check
verification process (actually there are 8, but we only need 7 of them for
our purposes here).  Fun fact: If you perform the 2 character quick check
in all 7 different ways, this is equivalent to doing a full checksum
verification.

This suggests a strategy of visiting your shares on a regular basis and
performing a different 2 character quick check each time, rotating through
the 7 different ways of performing it.

Moreover, these 7 different 2 character quick checks come with a prescribed
order that will accumulate BCH guarantees as you go along.  Assuming the
string isn't changing between visits then

* After the 1st table you are guaranteed to detect any 1 character error.
* After the 2nd table you are guaranteed to detect any 2 character error.
* After the 3rd table you are guaranteed to detect any 4 character error.
* After the 4th table you are guaranteed to detect any 5 character error.
* After the 5th table you are guaranteed to detect any 6 character error.
* After the 6th table you are guaranteed to detect any 7 character error.
* After the 7th table you are guaranteed to detect any 8 character error,
which is the guarantee of the full 13 character checksum.  You are also
guaranteed that the full 13 character checksum is now correct.

You could perform the checks out of order, and that is okay.  You will
eventually reach these BCH levels of guarantees, just not as quickly as if
you follow the prescribed order.

Of course, doing a series of 7 different 2 character quick checks is
overall more work than doing the full 13 character checksum validation.
But there is certainly an advantage in spreading the work out over time.
Each time you visit you still have the guarantee of catching any new 1
character error introduced since the last time you visited and a 99.9%
chance of catching any other random errors introduced since your last
visit.  Personally I am likely to follow such a validation strategy myself,
now that I am aware of it.


On Wed, Feb 22, 2023 at 10:30 PM Russell O'Connor 
wrote:

> After some consultation, I now see that generators for all degree 2 BCH
> codes, such as ours, are smooth and factor into quadratic and linear
> components.
>
> Anyhow the upshot of all this is that you can perform a "quickcheck"
> verification of the codex32 strings for whatever size of verification you
> want to do, 1 character, 2 characters, 3 characters, upto the full 13
> characters.  Each of these partial verifications will have BCH properties.
> A 1 character quickchecksum will guarantee to detect any 1 character
> error.  A 3 character quickchecksum will guarantee to detect any 2
> character error, etc.  There remains a 1 in 32^n chance of failing to
> detect larger numbers of errors where n is the size of your quickcheck.
>
> To illustrate, let's consider a quickcheck of size 2.  This can detect any
> 1 character error and will only have a 1/1024 chance of failing to detect
> other random errors.  Let's take the second test vector as our example: "
> MS12NAMEA320ZYXWVUTSRQPNMLKJHGFEDCAXRPP870HKKQRM"
>
> You start in a specified initial state with a pair of bech32 characters.
> For MS1 strings and a size 2 quickcheck it would be the pair of Bech32
> characters 'AS'.
>
> Next we "add" the first character after the prefix, which is '2' by using
> the addition volvelle or lookup table.  "Adding" '2' to 'S' yields '6' and
> our state becomes 'A6'.
>
> Next we have to look up 'A6' in a lookup table.  This table is too big to
> fit in the margin of this email, so I will have to omit it.  But it would
> have an entry mapping 'A6' -> 'QM'.  Our state becomes 'QM'
>
> From this point we have an even number of remaining characters in the
> input string and we can work 2 characters at a time. We "add" the next two
> data characters from our string, which are 'NA'.  Again, using the volvelle
> or lookup table we get that adding 'N' to 'Q' yields 'N', and adding 'A' to
> 'M' yields 'X'.  So our state is now 'NX'
>
> Next we look up 'NX' in this table I haven't given you and we will find an
> entry mapping 'NX' -> 'DX', making 'DX' our new state.
>
> We keep repeating this process alternating between adding pairs of
> characters and using this unstated lookup table all the way until the end
> where we will reach a final state which will be 'H9'.
>
> If you follow this procedure with any string (upto 400 bit master seeds)
> you will always end up in the state 'H9'.
>
> A specialized worksheet would help guide the process making the process
> easier to follow.
>
>
> This process is somewhat close to Peter Todd's suggestion of using a
> lookup table on "words", which in this case would be pairs of bech32
> 

Re: [bitcoin-dev] Codex32

[Russell O'Connor via bitcoin-dev]

Sorry for the repeated replies, but I would like to make one more remark
regarding the 1 character "quick check".

Because the 1 character "quick check" state is so small, the procedure
becomes simplified to just using a single table.  You start with the
specified initial state, which would be the bech32 character '9', and then
you have a lookup mapping (, ) ->
.  You go through the table for each character after the
prefix, updating the state as you go along. ('9','2') -> '0', then
('0','N') -> '4', and so on until you reach the final state which should be
'5'.  If you like volvelles, one could be designed to implement this lookup
table.

However, I do want to note that an adjustment could be made to the codex32
generator so that this 1 character "quick check" table would become
identical to the Bech32 addition table.  In other words the 1 character
quick check would become the same as adding up all the characters and
checking that you get the required final constant.

If this change were free to make, I would probably make it.  However such
an adjustment would come at a cost.  The current generator was chosen to
have three identical coefficients in a row (you can find the generator in
the appendix of the draft BIP).  This special property slightly eases the
computation needed when creating checksums by hand (no compromise to the
quality of the checksum itself).  If we made the above adjustment to the
codex32 generator, we would lose this property of having three identical
coefficients in a row.

Therefore, I am pretty hesitant to make this adjustment.  Firstly the 1
character quick check is simply too small to be safely used.  While it does
guarantee to detect single character errors, it has a 1 in 32 chance of
failing to detect more errors.  I think a 3% failure rate is pretty bad,
and would definitely recommend people performing quick checks use a minimum
size of 2 (which has a 0.1% failure rate).  Secondly the difference between
using the addition table/volvelle versus a specific table/volvelle for the
purpose of performing 1 character quick checks (which you ought not to be
doing anyways) is pretty minimal.  The addition table is possibly slightly
less error prone to use because it is symmetric, but other than that the
amount of work to do is pretty much the same either way.

My conclusion is that it isn't worth compromising the ease of hand
computation for the sake of possibly making a
too-low-quality-checksum-that-no-one-should-be-using slightly more
convenient, but I thought I should mention it at least.


On Wed, Feb 22, 2023 at 10:30 PM Russell O'Connor 
wrote:

> After some consultation, I now see that generators for all degree 2 BCH
> codes, such as ours, are smooth and factor into quadratic and linear
> components.
>
> Anyhow the upshot of all this is that you can perform a "quickcheck"
> verification of the codex32 strings for whatever size of verification you
> want to do, 1 character, 2 characters, 3 characters, upto the full 13
> characters.  Each of these partial verifications will have BCH properties.
> A 1 character quickchecksum will guarantee to detect any 1 character
> error.  A 3 character quickchecksum will guarantee to detect any 2
> character error, etc.  There remains a 1 in 32^n chance of failing to
> detect larger numbers of errors where n is the size of your quickcheck.
>
> To illustrate, let's consider a quickcheck of size 2.  This can detect any
> 1 character error and will only have a 1/1024 chance of failing to detect
> other random errors.  Let's take the second test vector as our example: "
> MS12NAMEA320ZYXWVUTSRQPNMLKJHGFEDCAXRPP870HKKQRM"
>
> You start in a specified initial state with a pair of bech32 characters.
> For MS1 strings and a size 2 quickcheck it would be the pair of Bech32
> characters 'AS'.
>
> Next we "add" the first character after the prefix, which is '2' by using
> the addition volvelle or lookup table.  "Adding" '2' to 'S' yields '6' and
> our state becomes 'A6'.
>
> Next we have to look up 'A6' in a lookup table.  This table is too big to
> fit in the margin of this email, so I will have to omit it.  But it would
> have an entry mapping 'A6' -> 'QM'.  Our state becomes 'QM'
>
> From this point we have an even number of remaining characters in the
> input string and we can work 2 characters at a time. We "add" the next two
> data characters from our string, which are 'NA'.  Again, using the volvelle
> or lookup table we get that adding 'N' to 'Q' yields 'N', and adding 'A' to
> 'M' yields 'X'.  So our state is now 'NX'
>
> Next we look up 'NX' in this table I haven't given you and we will find an
> entry mapping 'NX' -> 'DX', making 'DX' our new state.
>
> We keep repeating this process alternating between adding pairs of
> characters and using this unstated lookup table all the way until the end
> where we will reach a final state which will be 'H9'.
>
> If you follow this procedure with any string (upto 400 bit master seeds)
> you will always 

Re: [bitcoin-dev] Codex32

[Russell O'Connor via bitcoin-dev]

After some consultation, I now see that generators for all degree 2 BCH
codes, such as ours, are smooth and factor into quadratic and linear
components.

Anyhow the upshot of all this is that you can perform a "quickcheck"
verification of the codex32 strings for whatever size of verification you
want to do, 1 character, 2 characters, 3 characters, upto the full 13
characters.  Each of these partial verifications will have BCH properties.
A 1 character quickchecksum will guarantee to detect any 1 character
error.  A 3 character quickchecksum will guarantee to detect any 2
character error, etc.  There remains a 1 in 32^n chance of failing to
detect larger numbers of errors where n is the size of your quickcheck.

To illustrate, let's consider a quickcheck of size 2.  This can detect any
1 character error and will only have a 1/1024 chance of failing to detect
other random errors.  Let's take the second test vector as our example: "
MS12NAMEA320ZYXWVUTSRQPNMLKJHGFEDCAXRPP870HKKQRM"

You start in a specified initial state with a pair of bech32 characters.
For MS1 strings and a size 2 quickcheck it would be the pair of Bech32
characters 'AS'.

Next we "add" the first character after the prefix, which is '2' by using
the addition volvelle or lookup table.  "Adding" '2' to 'S' yields '6' and
our state becomes 'A6'.

Next we have to look up 'A6' in a lookup table.  This table is too big to
fit in the margin of this email, so I will have to omit it.  But it would
have an entry mapping 'A6' -> 'QM'.  Our state becomes 'QM'

>From this point we have an even number of remaining characters in the input
string and we can work 2 characters at a time. We "add" the next two data
characters from our string, which are 'NA'.  Again, using the volvelle or
lookup table we get that adding 'N' to 'Q' yields 'N', and adding 'A' to
'M' yields 'X'.  So our state is now 'NX'

Next we look up 'NX' in this table I haven't given you and we will find an
entry mapping 'NX' -> 'DX', making 'DX' our new state.

We keep repeating this process alternating between adding pairs of
characters and using this unstated lookup table all the way until the end
where we will reach a final state which will be 'H9'.

If you follow this procedure with any string (upto 400 bit master seeds)
you will always end up in the state 'H9'.

A specialized worksheet would help guide the process making the process
easier to follow.


This process is somewhat close to Peter Todd's suggestion of using a lookup
table on "words", which in this case would be pairs of bech32 characters,
and adding values together.  The catch is that the addition is done with
Bech32 addition rather than calculator addition, which I accept is a
moderately large catch.

Anyhow, the point is that you can do this sort of partial verification by
hand to whatever degree you like, if you are in a rush and are willing to
accept larger chances of failing to catch random errors.


On Wed, Feb 22, 2023 at 2:01 PM Russell O'Connor 
wrote:

> After some poking around at the math, I do see that the 13 character
> generator (for regular sized shares) is reasonably "smooth", having roots
> at T{11}, S{16}, and C{24}.
>
> This means we could build a "quick check" worksheet to evaluate the string
> modulo (x - T) to verify a 5 bit checksum, whose operation would be similar
> to the existing checksum worksheet in structure but significantly less work.
>
> Perhaps 5 bits is too short, and it is more reasonable working modulo (x -
> T)*(x - S) to get a 10 bit checksum.  A worksheet for a 15 bit checksum is
> also an option, and possibly others well depending on the size of the other
> factors.  I think this process is would be about as simple as any other
> comparable hand operated checksum over the bech32 alphabet would be.
>
> I haven't looked into the smoothness of the long generator for seeds that
> are greater than 400 bits.  If it isn't smooth and smoother options are
> available, perhaps it should be changed.
>
> On Wed, Feb 22, 2023 at 11:29 AM Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Sun, Feb 19, 2023 at 10:12:51PM +, Andrew Poelstra via bitcoin-dev
>> wrote:
>> > > What really did catch my attention, but which was kind of buried in
>> the
>> > > project documentation, is the ability to verify the integrity of each
>> > > share independently without using a computer.  For example, if I
>> store a
>> > > share with some relative who lives thousands of kilometers away, I'll
>> be
>> > > able to take that share out of its tamper-evident bag on my annual
>> > > holiday visit, verify that I can still read it accurately by
>> validating
>> > > its checksum, and put it into a new bag for another year.  For this
>> > > procedure, I don't need to bring copies of any of my other shares,
>> > > allowing them (and my seed) to stay safe.
>> > >
>> >
>> > This is good feedback. I strongly agree that this is the big selling
>> > point for this -- that you can vet 

Re: [bitcoin-dev] Codex32

[Russell O'Connor via bitcoin-dev]

After some poking around at the math, I do see that the 13 character
generator (for regular sized shares) is reasonably "smooth", having roots
at T{11}, S{16}, and C{24}.

This means we could build a "quick check" worksheet to evaluate the string
modulo (x - T) to verify a 5 bit checksum, whose operation would be similar
to the existing checksum worksheet in structure but significantly less work.

Perhaps 5 bits is too short, and it is more reasonable working modulo (x -
T)*(x - S) to get a 10 bit checksum.  A worksheet for a 15 bit checksum is
also an option, and possibly others well depending on the size of the other
factors.  I think this process is would be about as simple as any other
comparable hand operated checksum over the bech32 alphabet would be.

I haven't looked into the smoothness of the long generator for seeds that
are greater than 400 bits.  If it isn't smooth and smoother options are
available, perhaps it should be changed.

On Wed, Feb 22, 2023 at 11:29 AM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sun, Feb 19, 2023 at 10:12:51PM +, Andrew Poelstra via bitcoin-dev
> wrote:
> > > What really did catch my attention, but which was kind of buried in the
> > > project documentation, is the ability to verify the integrity of each
> > > share independently without using a computer.  For example, if I store
> a
> > > share with some relative who lives thousands of kilometers away, I'll
> be
> > > able to take that share out of its tamper-evident bag on my annual
> > > holiday visit, verify that I can still read it accurately by validating
> > > its checksum, and put it into a new bag for another year.  For this
> > > procedure, I don't need to bring copies of any of my other shares,
> > > allowing them (and my seed) to stay safe.
> > >
> >
> > This is good feedback. I strongly agree that this is the big selling
> > point for this -- that you can vet shares/seeds which *aren't* being
> > actively used, without exposing them to the sorts of threats associated
> > with active use.
> >
> > We should make this more prominent in the BIP motivation.
>
> I don't think that use-case is a good selling point. The checksum that
> Codex32
> uses is much more complex than necessary if you are simply verifying a
> share by
> itself.
>
> A *much* simpler approach would be to use a simple mod N = 0 checksum,
> either
> by creating the seed such that each share passes, or by just storing an
> additional word/symbol with the seed in such a way that sum(words) mod N =
> 0
> passes. This approach is not only possible to compute by hand with a
> word/symbol->number lookup table, and pen and paper or a calculator. It's
> so
> simple they could probably *remember* how to do it themselves.
>
>
> Secondly, if all shares have mod N checksums, it may be sufficient for
> everyone
> to write down the checksums of the *other* shares, to verify they are the
> correct ones and a different (otherwise correct) share hasn't accidentally
> been
> substituted.
>
> Indeed, with some brute forcing and small checksums, I'd expect it to be
> mathematically possible to generate Shamir's secret sharing shards such
> that
> every shard can share the *same* checksum. In which case the share
> verification
> procedure would be to simply ask every share holder to verify the checksum
> manually using the mod N procedure, and then verify that each share holder
> has
> the same checksum. This would be less error prone in terms of leaking
> information accidentally if the checksum was obviously *not* part of the
> share:
> eg by encoding the share with words, and the checksum with a number.
>
> Obviously, small checksums aren't fool proof. But we're probably better off
> creating a relatively easy procedure with a 1-in-1000 chance of an error
> going
> undetected than a complex procedure that people don't actually do at all.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> ___
> 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] Codex32

[Russell O'Connor via bitcoin-dev]

On Sun, Feb 19, 2023 at 3:13 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>Codex32 allows the individual to periodically perform their
>recollection on paper in a private room without electronics and use
>nothing but a pen and some loookup tables (or a paper device) to
>verify that they recalled the string correctly (and its checksum can
>help with correcting up to several errors, although you might need a
>computer for error location and correction assistance).
>

While perhaps not entirely impossible, doing error correction by hand is
far more difficult than just the error detection process.
Fortunately, error correction can be aided by a computer needing very
little trust.

When doing hand computation of the checksum, there is an error if the final
"residue" is different from the value given in the codex32 spec.
After double checking your hand computation by redoing it, if you still get
the same incorrect residue, there is an error in your share data somewhere.

What you can do is plug in the residue that you did compute into a
computer, and have it produce an error correction string.
You can then, by hand, add this error correction string to your share to
get a corrected share.

If it were the case that all types of character errors were equally likely
(as in during an error any character is equally likely to be transformed
into any other character), then the computer would gain zero information
about your actual share data.  Of course, it is not in fact the case that
all transcription errors are equally likely, and so the computer can learn
a little bit about your share. The fewer errors that are made, the less
data it can recover. If you only have one character in error, then 5 bits
is the most data it can recover, and that is assuming that it can somehow
infer your error perfectly from the delta of the error correction, which
isn't actually going to be the case.

Of course, a single share from a split secret has no information about your
master seed (the master seed is hidden in the correlation between different
shares).  So learning partial information about one share isn't going to be
enough by itself to even begin compromising your master key.

This all still needs to be written up in more detail, but I figured I would
give a preview here.

- Hierarchy: Codex32 does not natively provide support for nested 
>whereas SLIP39 does.  E.g., in SLIP39, you can require 2-of-3 for
>{me, family, friends} where me is 2-of-3 {fire_safe, bank_safe,
>buried_in_woods}, family is 1-of-3 {alice, bob, carol}, and friends
>are 2-of-5 {d, e, f, g, h}.  I assume you can do the same with Codex32
>by using the share for one level as the secret for the next level,
>although this is not described in the protocol.
>

There was a design for a second level share scheme floating around
somewhere. I'll have to dig it up. As I recall this is made slightly more
complicated by needing to incorporate share metadata (i.e. the share index)
when doing a second split, but it seemed doable at the time.


> - Versioning: Codex32's metadata can store version information for
>wallets that use implicit BIP32 paths (e.g. BIP44/49/84/86), although
>this would cut into the space available for users to set their own
>metadata and it is not specified in the draft BIP.  SLIP39 also
>doesn't specify anything about implicit path versioning and, AFAICT,
>doesn't have any room to store such metadata without reducing seed
>entropy.
>

Personally, I don't consider the derivation path / descriptor data as that
sensitive, and I would recommend making wide backups of that data.
It certainly would make sense to store descriptor data alongside wherever
you keep your shares, and more places beyond that.
On the other hand, if you are trying to keep your shares innocuous somehow,
perhaps you won't be able to keep the descriptor data alongside your shares.

When I first saw the post about this, it was unclear to me that it was a
> serious project, but I've become increasingly interested as I researched
> it.  I'm not personally that interested in generating entropy from dice
> or encoding shares by hand---it's already imperative that I acquire a
> trustworthy computer and load it with trustworthy software in order to
> use my seed securely, so I might as well have it generate my seeds and
> my
> recovery codes for me.
>

I do think hardware wallets are great, and overall provide a lot of
practical protection.  What is notable is that once the secrets are loaded
onto a hardware wallet, as long as that wallet remains isolated, it cannot
leak any secrets.

Of course, a wallet needs to interact with the Bitcoin protocol and P2P
network, at least indirectly, in order to  function, so we must break that
isolation.  However, if we can limit the communication capabilities of a
hardware wallet, even a malicious wallet shouldn't be able to leak the

Re: [bitcoin-dev] Codex32

[Russell O'Connor via bitcoin-dev]

On Sun, Feb 19, 2023 at 5:13 PM Andrew Poelstra via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sun, Feb 19, 2023 at 10:13:33AM -1000, David A. Harding wrote:
>
> I'm curious about whether there's a way to prevent this attack without
> > otherwise compromising the properties of the code?  For example, some
> > extra data that Bob can carry around (or memorize) for verifying the
> > shares haven't changed, but which is not otherwise needed for recovery
> > (so there's no problem if it's lost).
> >
>
> Unfortunately not, as near as I can tell ... one way to think of this is
> that Alice can flip a lot of random tiles then "error correct" it to get
> a new valid, but incorrect, seed. So as long as we support error
> correction it'll be possible to wreck seeds in this way.
>
> It's actually even worse than this ... as long as there's a clearly
> defined "checksum" at the end of a share, Alice will be able to mangele
> tiles and then just re-compute the checksum at the end.
>
> So what we really need to prevent this is something like a MAC: where
> Bob has a secret value which gets input into the checksum somehow, which
> Alice can't create valid checksums without knowing. Unfortunately I
> don't see any way to do this with linear codes. With a hash-based
> "checksum" a la BIP39 it would definitely be possible, but of course,
> not hand-computable.
>

Speaking off the cuff and as a non-cryptographer (i.e do NOT rush off and
do this without any vetting) but Christopher Allen once referred me to an
cypher tile set called LS47 .  If we
set aside the cypertext, I suspect we can form a MAC by recording some
random initial tile configuration, running the LS47 algorithm, and
recording the final tile configuration.  These records are not sensitive as
(presumably!) the share data is not recoverable from just knowing these two
configurations.  So one can keep these records with you, digitally sign
them or whatever, and then take them to your share on a regular basis to
rerun the LS47 algorithm to see if you still get the same final state from
the initial state.

Perhaps something more specific to Bech32 could be designed, but otherwise
this (alleged) MAC process isn't Codex32 specific.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network

[Russell O'Connor via bitcoin-dev]

On Sat, Feb 18, 2023 at 5:11 AM vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Also, it gives us a hint, that if any Script upgrade will be considered in
> the future, we can think about doing it in a way, where unused parts can be
> pruned, without invalidating signatures.
>

FWIW, pruning unused case branches is a core design principle of the
Simplicity language I am developing.

That being said, even this is not enough to thwart agents that specifically
desire to post unused data blobs as part of their programs.  This is
largely because there are many mathematical expressions for what is
equivalently an identity function.  Think computing (x ^ 257) mod 257 (see
Fermat's little theorem).

Even in Simplicity users can write Word **; unit which is
roughly equivalent PUSH ** DROP in Script.  I don't even bother
trying to prevent it.  Doing so just adds more consensus complexity, and
only raises the bar slightly on how to work around it.

Simplicity's pruning is instead meant as a way to (usually) lower costs for
users who aren't actively trying to spam the network.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Codex32

[Russell O'Connor via bitcoin-dev]

I've been asked by Dr. Curr and Professor Snead to forward this message to
this mailing list, as it may be of general interest to Bitcoin users.

Dear Colleague:

In 1967, during excavation for the construction of a new shopping center in
Monroeville, Pennsylvania, workers uncovered a vault containing a cache of
ancient scrolls[1].  Most were severely damaged, but those that could be
recovered confirmed the existence of a secret society long suspected to
have
been active in the region around the year 200 BC.

Based on a translation of these documents, we now know that the society,
the
Cult of the Bound Variable, was devoted to the careful study of
computation,
over two millennia before the invention of the digital computer.

While the Monroeville scrolls make reference to computing machines made of
sandstone, most researchers believed this to be a poetic metaphor and that
the
"computers" were in fact the initiates themselves, carrying out the
unimaginably tedious steps of their computations with reed pens on
parchment.

Within the vault, a collection of sandstone wheels marked in a language
consisting of 32 glyphs was found. After 15 years of study, we have
successfully
completed the translation of what is known as "Codex32," a document that
describes the functions of the wheels. It was discovered that the wheels
operate
a system of cryptographic computations that was used by cult members to
safeguard their most valuable secrets.

The Codex32 system allows secrets to be carved into multiple tablets and
scattered to the far corners of the earth. When a sufficient number of
tablets are
brought together the stone wheels are manipulated in a manner to recover the
secrets. This finding may be of particular interest to the Bitcoin
community.

Below we provide a summary of the cult's secret sharing system, which is
graciously hosted at
<
https://github.com/apoelstra/bips/blob/2023-02--volvelles/bip-.mediawiki
>.
We are requesting a record assignment in the Bibliography of Immemorial
Philosophy (BIP) repository.

Thank you for your consideration.

Dr. Leon O. Curr and Professor Pearlwort Snead
Department of Archaeocryptography
Harry Q. Bovik Institute for the Advancement

[1] http://www.boundvariable.org/task.shtml

-BEGIN BIP-


  BIP: 
  Layer: Applications
  Title: codex32
  Author: Leon Olsson Curr and Pearlwort Sneed 
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
  Status: Draft
  Type: 
  Created: 2023-02-13
  License: BSD-3-Clause
  Post-History: FIXME


==Introduction==

===Abstract===

This document describes a standard for backing up and restoring the master
seed of a
[https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032]
hierarchical deterministic wallet, using Shamir's secret sharing.
It includes an encoding format, a BCH error-correcting checksum, and
algorithms for share generation and secret recovery.
Secret data can be split into up to 31 shares.
A minimum threshold of shares, which can be between 1 and 9, is needed to
recover the secret, whereas without sufficient shares, no information about
the secret is recoverable.

===Copyright===

This document is licensed under the 3-clause BSD license.

===Motivation===

BIP-0032 master seed data is the source entropy used to derive all private
keys in an HD wallet.
Safely storing this secret data is the hardest and most important part of
self-custody.
However, there is a tension between security, which demands limiting the
number of backups, and resilience, which demands widely replicated backups.
Encrypting the seed does not change this fundamental tradeoff, since it
leaves essentially the same problem of how to back up the encryption key(s).

To allow users freedom to make this tradeoff, we use Shamir's secret
sharing, which guarantees that any number of shares less than the threshold
leaks no information about the secret.
This approach allows increasing safety by widely distributing the generated
shares, while also providing security against the compromise of one or more
shares (as long as fewer than the threshold have been compromised).

[https://github.com/satoshilabs/slips/blob/master/slip-0039.md SLIP-0039]
has essentially the same motivations as this standard.
However, unlike SLIP-0039, this standard also aims to be simple enough for
hand computation.
Users who demand a higher level of security for particular secrets, or have
a general distrust in digital electronic devices, have the option of using
hand computation to backup and restore secret data in an interoperable
manner.
Note that hand computation is optional, the particular details of hand
computation are outside the scope of this standard, and implementers do not
need to be concerned with this possibility.

[https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039]
serves the same purpose as this standard: encoding master seeds for storage
by users.
However, BIP-0039 has no error-correcting ability, cannot 

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Russell O'Connor via bitcoin-dev]

Yes.  If you would otherwise sign the tapleaf, then I would recommend also
signing the entire tapbranch.



On Sat, Feb 11, 2023 at 12:15 AM Anthony Towns  wrote:

> On 9 February 2023 12:04:16 am AEST, Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >The fix for the bug is to sign the entire tapbranch instead of the
> tapleaf.
> >
> >On Wed., Feb. 8, 2023, 04:35 Michael Folkson, <
> michaelfolk...@protonmail.com>
> >wrote:
> >
> >> Hi Andrew
> >>
> >> > There is a bug in Taproot that allows the same Tapleaf to be repeated
> >> multiple times in the same Taproot, potentially at different Taplevels
> >> incurring different Tapfee rates.
> >> >
> >> > The countermeasure is that you should always know the entire Taptree
> >> when interacting with someone's Tapspend.
> >>
> >> I wouldn't say it is a "bug" unless there is a remedy for the bug that
> >> wasn't (and retrospectively should have been) included in the Taproot
> >> design. In retrospect and assuming you could redesign the Taproot
> consensus
> >> rules again today would you prevent spending from a valid P2TR address
> if a
> >> repeated Tapleaf hash was used to prove that a spending path was
> embedded
> >> in a Taproot tree? That's the only thing I can think of to attempt to
> >> remedy this "bug" and it would only be a partial protection as proving a
> >> spending path exists within a Taproot tree only requires a subset of the
> >> Tapleaf hashes.
> >>
> >> I only point this out because there seems to be a push to find "bugs"
> and
> >> "accidental blowups" in the Taproot design currently. No problem with
> this
> >> if there are any, they should definitely be highlighted and discussed if
> >> they do exist. The nearest to a possible inferior design decision thus
> far
> >> that I'm aware of is x-only pubkeys in BIP340 [0].
> >>
> >> Thanks
> >> Michael
> >>
> >> [0]:
> >>
> https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#a-retrospective-look-at-bip340
> >>
> >> --
> >> Michael Folkson
> >> Email: michaelfolkson at protonmail.com
> >> Keybase: michaelfolkson
> >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> >>
> >> --- Original Message ---
> >> On Tuesday, February 7th, 2023 at 18:35, Russell O'Connor via
> bitcoin-dev <
> >> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> There is a bug in Taproot that allows the same Tapleaf to be repeated
> >> multiple times in the same Taproot, potentially at different Taplevels
> >> incurring different Tapfee rates.
> >>
> >> The countermeasure is that you should always know the entire Taptree
> when
> >> interacting with someone's Tapspend.
> >>
> >>
> >> On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev <
> >> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >>>
> >>> Some people highlighted some minor problems with my last email:
> >>>
> >>> On Tue, Feb 07, 2023 at 01:46:22PM +, Andrew Poelstra via
> bitcoin-dev
> >>> wrote:
> >>> >
> >>> > 
> >>> >
> >>> > [1] https://bitcoin.sipa.be/miniscript/
> >>> > [2] In Taproot, if you want to prevent signatures migrating to
> another
> >>> > branch or within a branch, you can use the CODESEPARATOR opcode
> >>> > which was redisegned in Taproot for exactly this purpose... we
> >>> > really did about witness malleation in its design!
> >>>
> >>> In Taproot the tapleaf hash is always covered by the signature (though
> >>> not in some ANYONECANPAY proposals) so you can never migrate signatures
> >>> between tapbranches.
> >>>
> >>> I had thought this was the case, but then I re-confused myself by
> >>> reading BIP 341  which has much of the sighash specified, but not
> >>> all of it! The tapleaf hash is added in BIP 342.
> >>>
> >>> >
> >>> > If you want to prevent signatures from moving around *within* a
> >>> > branch,
> >>> >
> >>>
> >>> And this sentence I just meant to delete :)
> >>>
> >>>
> >>> --
> >>> Andrew Poelstra
> >>> Director of Research, Blockstream
> >>> Email: apoelstra at wpsoftware.net
> >>> Web: https://www.wpsoftware.net/andrew
> >>>
> >>> The sun is always shining in space
> >>> -Justin Lewis-Webster
> >>>
> >>> ___
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev@lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>
> >>
> >>
>
> Is this something that should be fixed in bip118 signatures then?
>
> Cheers,
> aj
> --
> Sent from my phone.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Russell O'Connor via bitcoin-dev]

The fix for the bug is to sign the entire tapbranch instead of the tapleaf.

On Wed., Feb. 8, 2023, 04:35 Michael Folkson, 
wrote:

> Hi Andrew
>
> > There is a bug in Taproot that allows the same Tapleaf to be repeated
> multiple times in the same Taproot, potentially at different Taplevels
> incurring different Tapfee rates.
> >
> > The countermeasure is that you should always know the entire Taptree
> when interacting with someone's Tapspend.
>
> I wouldn't say it is a "bug" unless there is a remedy for the bug that
> wasn't (and retrospectively should have been) included in the Taproot
> design. In retrospect and assuming you could redesign the Taproot consensus
> rules again today would you prevent spending from a valid P2TR address if a
> repeated Tapleaf hash was used to prove that a spending path was embedded
> in a Taproot tree? That's the only thing I can think of to attempt to
> remedy this "bug" and it would only be a partial protection as proving a
> spending path exists within a Taproot tree only requires a subset of the
> Tapleaf hashes.
>
> I only point this out because there seems to be a push to find "bugs" and
> "accidental blowups" in the Taproot design currently. No problem with this
> if there are any, they should definitely be highlighted and discussed if
> they do exist. The nearest to a possible inferior design decision thus far
> that I'm aware of is x-only pubkeys in BIP340 [0].
>
> Thanks
> Michael
>
> [0]:
> https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#a-retrospective-look-at-bip340
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> --- Original Message ---
> On Tuesday, February 7th, 2023 at 18:35, Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> There is a bug in Taproot that allows the same Tapleaf to be repeated
> multiple times in the same Taproot, potentially at different Taplevels
> incurring different Tapfee rates.
>
> The countermeasure is that you should always know the entire Taptree when
> interacting with someone's Tapspend.
>
>
> On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> Some people highlighted some minor problems with my last email:
>>
>> On Tue, Feb 07, 2023 at 01:46:22PM +, Andrew Poelstra via bitcoin-dev
>> wrote:
>> >
>> > 
>> >
>> > [1] https://bitcoin.sipa.be/miniscript/
>> > [2] In Taproot, if you want to prevent signatures migrating to another
>> > branch or within a branch, you can use the CODESEPARATOR opcode
>> > which was redisegned in Taproot for exactly this purpose... we
>> > really did about witness malleation in its design!
>>
>> In Taproot the tapleaf hash is always covered by the signature (though
>> not in some ANYONECANPAY proposals) so you can never migrate signatures
>> between tapbranches.
>>
>> I had thought this was the case, but then I re-confused myself by
>> reading BIP 341  which has much of the sighash specified, but not
>> all of it! The tapleaf hash is added in BIP 342.
>>
>> >
>> > If you want to prevent signatures from moving around *within* a
>> > branch,
>> >
>>
>> And this sentence I just meant to delete :)
>>
>>
>> --
>> Andrew Poelstra
>> Director of Research, Blockstream
>> Email: apoelstra at wpsoftware.net
>> Web: https://www.wpsoftware.net/andrew
>>
>> The sun is always shining in space
>> -Justin Lewis-Webster
>>
>> ___
>> 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] Unenforceable fee obligations in multiparty protocols with Taproot inputs

[Russell O'Connor via bitcoin-dev]

There is a bug in Taproot that allows the same Tapleaf to be repeated
multiple times in the same Taproot, potentially at different Taplevels
incurring different Tapfee rates.

The countermeasure is that you should always know the entire Taptree when
interacting with someone's Tapspend.


On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Some people highlighted some minor problems with my last email:
>
> On Tue, Feb 07, 2023 at 01:46:22PM +, Andrew Poelstra via bitcoin-dev
> wrote:
> >
> > 
> >
> > [1] https://bitcoin.sipa.be/miniscript/
> > [2] In Taproot, if you want to prevent signatures migrating to another
> > branch or within a branch, you can use the CODESEPARATOR opcode
> > which was redisegned in Taproot for exactly this purpose... we
> > really did about witness malleation in its design!
>
> In Taproot the tapleaf hash is always covered by the signature (though
> not in some ANYONECANPAY proposals) so you can never migrate signatures
> between tapbranches.
>
> I had thought this was the case, but then I re-confused myself by
> reading BIP 341  which has much of the sighash specified, but not
> all of it! The tapleaf hash is added in BIP 342.
>
> >
> > If you want to prevent signatures from moving around *within* a
> > branch,
> >
>
> And this sentence I just meant to delete :)
>
>
> --
> Andrew Poelstra
> Director of Research, Blockstream
> Email: apoelstra at wpsoftware.net
> Web:   https://www.wpsoftware.net/andrew
>
> The sun is always shining in space
> -Justin Lewis-Webster
>
> ___
> 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] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Russell O'Connor via bitcoin-dev]

On Sat., Feb. 4, 2023, 21:01 Peter Todd,  wrote:

>
>
> On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via bitcoin-dev
>  wrote:
> >Since bytes in the witness are cheaper than bytes in the script pubkey,
> >there is a crossover point in data size where it will simply be cheaper to
> >use witness data.  Where that crossover point is depends on the finer
> >details of the overhead of the two methods, but you could make some
> >reasonable assumptions.  Such a calculation could form the basis of a
> >reasonable OP_RETURN proposal.  I don't know if it would be persuasive,
> but
> >it would at least be coherent.
>
> I don't think it's worth the technical complexity trying to carefully
> argue a specific limit. Let users decide for themselves how they want to
> use OpReturn.
>

Even better.

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

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

[Russell O'Connor via bitcoin-dev]

Since bytes in the witness are cheaper than bytes in the script pubkey,
there is a crossover point in data size where it will simply be cheaper to
use witness data.  Where that crossover point is depends on the finer
details of the overhead of the two methods, but you could make some
reasonable assumptions.  Such a calculation could form the basis of a
reasonable OP_RETURN proposal.  I don't know if it would be persuasive, but
it would at least be coherent.

On Sat., Feb. 4, 2023, 18:17 Aymeric Vitte via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I don't know, what number would you advise? When I made the
> bitcoin-transactions nodejs module some years ago the limit (from the
> specs) was 512B
>
> It's not a fork, super easy to do
>
> And necessary because bitcoin on ground of I don't know what rule
> allowing the IF/ENDIF "unlimited" storage just mimics ethereum for the
> worse, and is again quite dubious to use
>
>
> Le 04/02/2023 à 23:18, Christopher Allen a écrit :
> > 520 because that is a similar limit in taproot? Some multiple of
> > hash+signature+metadata to satisfy others (that still might not be
> > satisfied by any choice).
>
>
> ___
> 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] Validity Rollups on Bitcoin

[Russell O'Connor via bitcoin-dev]

On Fri, Nov 4, 2022 at 4:04 PM Trey Del Bonis via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Instead of that approach, I assume we have fairly granular transaction
> introspection opcodes from a list in Elements [2] (which seem like they
> aren't actually used in mainnet Liquid?)


These opcodes went live on Liquid along with Taproot <
https://blog.liquid.net/taproot-on-liquid-is-now-live/>, so feel free to
try them out on Elements or Liquid.

One complicated part is the actual proof verification.  I had considered
> looking into what it would take to build a verifying for a modern proof
> system if we used pairings as a primitive, but it turns out even that is
> pretty involved even in a higher level language (at least for PLONK [3])
> and would be error-prone when trying to adapt the code for new circuits
> with differently-shaped public inputs.  The size of the code on-chain
> alone would probably make it prohibitively expensive, so it would be a
> lot more efficient just to assume we can introduce a specific opcode for
> doing a proof verification implemented natively.  The way I assumed it
> would work is taking the serialized proof, a verification key, and the
> public input as separate stack items.  The public input is the
> concatenation of the state and deposit commitments we took from the
> input, the batch post-state commitment (provided as part of the
> witness), data from transaction outputs corresponding to
> internally-initiated withdrawals from the rollup, and the rollup batch
> data itself (also passed as part of the witness).
>

I'd be interested in knowing what sort of Simplicity Jets would facilitate
rollups.  I suppose some pairing-friendly curve operations would do.  It
might not make the first cut of Simplicity, but we will see.

Simplicity's design doesn't have anything like a 520 byte stack limit.
There is just going to be an overall maximum allowed Simplicity evaluation
state size of some value that I have yet to decide.  I would imagine it to
be something like 1MB.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Russell O'Connor via bitcoin-dev]

On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> However, what *is* important about what Satoshi wrote is that it is sort
> of the "social contract" of what Bitcoin is that we can all sort of
> minimally agree to. This makes it clear, when we try to describe Bitcoin
> with differing assumptions than in the whitepaper, what the changes are and
> why we think the system might support those claims. But if we can't prove
> the new description sound, such as showing tip mining to be rational in a
> fully adversarial model, it doesn't mean Bitcoin doesn't work as promised,
> since all that was promised originally is functioning under an honest
> majority. Caveat Emptor!
>

I still think it is misguided to think that the "honest" (i.e. rule
following) majority is to just be accepted as an axiom and if it is
violated, well, then sorry.  The rules need to be incentive compatible for
the system to be functional.  The honest majority is only considered an
assumption because even if following the rules were clearly the 100%
dominant strategy, this doesn't prove that the majority is honest, since
mathematics cannot say what is happening in the real world at any given
time.  Still, we must have a reason to think that the majority would be
honest, and that reasoning should come from an argument that the rule set
is incentive compatible.

The stability of mining, i.e. the incentives to mine on the most work
chain, is actually a huge concern, especially in a future low subsidy
environment.  There is actually much fretting about this issue, and rightly
so.  We don't actually know that Bitcoin can function in a low subsidy
environment because we have never tested it.  Bitcoin could still end up a
failure if that doesn't work out.  My current understanding/guess is that
with a "thick mempool" (that is lots of transactions without large gaps in
fee rates between them) and/or miners rationally leaving behind
transactions to encourage mining on their block (after all it is in a
miner's own interest not to have their block orphaned), that mining will be
stable.  But I don't know this for sure, and we cannot know with certainty
that we are going to have a "thick mempool" when it is needed.

It is most certainly the case that one can construct situations where not
mining on the tip is going to be the prefered strategy.  But even if that
happens on occasion, it's not like the protocol immediately collapses,
because mining off the tip is indistinguishable from being a high latency
miner who simply didn't receive the most work block in time.  So it is more
of a question of how rare does it need to be, and what can we do to reduce
the chances of such situations arising (e.g. updating our mining policy to
leave some transactions out based on current (and anticipated) mempool
conditions, or (for a sufficiently capitalized miner) leave an explicit,
ANYONECANSPEND transaction output as a tip for the next miner to build upon
mined blocks.)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Russell O'Connor via bitcoin-dev]

>From my limited academic interactions, people generally take the "honest"
to mean following the rules (regardless of how bad it is for you to follow
those rules).  This has in turn led to some blockchain designs based on
their own absurd set of rules, and simply waiving away their issues by
stipulating their own honest majority or supermajority requirement.  For
example, a proof of stake blockchain might require as a rule that users
securely delete their signing keys after a period of time, and prove their
blockchain secure under these rules.  They then argue that so long as the
"honest" majority follows this rule, then there is no risk of
reorganization.  If enough users don't delete their signing keys, well
their honest majority assumption is violated, so anything goes.

The thing is that it is most certainly in each user's interest to *not*
delete their signing keys.   Each user has strictly more power and options
available by keeping their keys and not deleting them.  This rule violation
is undetectable, at least until it is too late and a coalition decides to
try to collaborate for a reorg to their advantage.

It is not reasonable to build a distributed pseudonymous system built on
arbitrary rules and then simply define your system to be secure by fiat.
Users need an incentive to follow the rules of the system or it just won't
work.  In particular, the rules ought to form a Nash Equilibrium, and this
is violated by, for example, a requirement that users delete their signing
keys.  If Bitcoin relied on users acting against their own interest to
function, I doubt Bitcoin would be in operation today.  Certainly I would
have no interest in it.

While it doesn't really matter, I do believe Satoshi was also aware that
the rules cannot just be arbitrary, with no incentive to follow them.
After all, he did note that it was designed to be in the miner's self
interest to build upon the longest (most work) chain, even if that point
ended up being rather involved.  That is to say, I don't think that an
"honest" (i.e rule following) majority is meant to be taken as an
assumption, rather it is something that ought to be a consequence of the
design.

Anyhow, the above is simply a comment on "honest majority", and I'm not
trying to make a specific claim about RBF here, though I do have my
opinions and I do see how it is related.

On Sun, Oct 16, 2022 at 1:36 PM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The Bitcoin white paper says:
>
> The proof-of-work also solves the problem of determining representation in
> majority decision
> making. If the majority were based on one-IP-address-one-vote, it could be
> subverted by anyone
> able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote.
> The majority
> decision is represented by the longest chain, which has the greatest
> proof-of-work effort invested
> in it. If a majority of CPU power is controlled by honest nodes, the
> honest chain will grow the
> fastest and outpace any competing chains. To modify a past block, an
> attacker would have to
> redo the proof-of-work of the block and all blocks after it and then catch
> up with and surpass the
> work of the honest nodes. We will show later that the probability of a
> slower attacker catching up
> diminishes exponentially as subsequent blocks are added.
>
>
> This, Satoshi (who doesn't really matter anyways I guess?) claimed that
> for Bitcoin to function properly you need a majority honest nodes.
>
> There are multiple behaviors one can describe as honest, and economically
> rational or optimizing is not necessarily rational.
>
> For example, if I run a shop that takes rain checks, but I sell an item to
> a higher bidder who didn't have a hold on the item, that is not honest, but
> it may be selfish profit maximizing.
>
> Satoshi said an honest majority is required for the chain to be extended.
> Honest is not really defined though. Honesty, in my definition, is that you
> follow a pre specified rule, rational or not.
>
> It seems a lot of the RBF controversy is that Protocol developers have
> aspired to make the honest behavior also be the rational behavior. This is
> maybe a good idea because, in theory, if the honest behavior is rational
> then we can make a weaker assumption of selfishness maximizing a parameter.
>
> However, Satoshi did not particularly bound what aspects of honesty are
> important for the network, because there isn't a spec defining exactly what
> is honest or not. And also as soon as people are honest, you can rely on
> that assumption for good effect.
>
> And sometimes, defining an honest behavior can be creating a higher
> utility system because most people are "law abiding citizens" who might not
> be short term rational. For example, one might expect that miners would be
> interested in making sure lightning closes are "accurate" because
> increasing the utility of lightning is good for Bitcoin, even if it is
> irrational.
>
> It 

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

[Russell O'Connor via bitcoin-dev]

Oops, you are right.  We need the bribe to be the output of the coinbase,
but due to the maturity rule, it isn't really a bribe.

Too bad coinbases cannot take other coinbase outputs as inputs to bypass
the maturity rule.

I guess that means the bribe has to be by leaving transactions in the
mempool.

Also your point about centralization pressure is well taken.

On Mon, Jul 11, 2022 at 5:56 PM Peter Todd  wrote:

> On Mon, Jul 11, 2022 at 05:36:52PM -0400, Peter Todd via bitcoin-dev wrote:
> > On Mon, Jul 11, 2022 at 04:35:02PM -0400, Russell O'Connor via
> bitcoin-dev wrote:
> > > > What happens after that I'm not sure.
> > > >
> > >
> > > Miners will learn to create anyone-can-spend outputs to bribe other
> miners
> > > to build on their block rather than reorg it.  (Due to the coinbase
> > > maturity, this will require some amount of floating capital.)
> >
> > ...and that's a disaster for mining centralization, because the smaller
> miners
> > need to pay larger bribes than larger miners. Not to mention having to
> keep
> > capital around to do it.
>
> Also, note how from a practical point of view, we'll need to add a new
> type of
> tx that's only valid in a specific block, or other miners will just reorg
> those
> anyone-can-spend outputs to steal them. It's not all that trivial to
> actually
> do that... you'd have to have a signature that commits to the non-segwit
> part
> of the coinbase outputs. Ugh.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

[Russell O'Connor via bitcoin-dev]

On Mon, Jul 11, 2022 at 2:19 PM Bram Cohen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If transaction fees came in at an even rate over time all at the exact
> same level then they work fine for security, acting similarly to fixed
> block rewards. Unfortunately that isn't how it works in the real world.
> There's a very well established day/night cycle with fees going to zero
> overnight and even longer gaps on weekends and holidays. If in the future
> Bitcoin is entirely dependent on fees for security (scheduled very
> strongly) and this pattern keeps up (overwhelmingly likely) then this is
> going to become a serious problem.
>
> What's likely to happen is that at first there will simply be no or very
> few blocks mined overnight. There are likely to be some, as miners at first
> turn off their mining rigs completely overnight then adopt the more
> sophisticated strategy of waiting until there are enough fees in the
> mempool to warrant attempting to make a block and only then doing it.
> Unfortunately the gaming doesn't end there. Eventually the miners with
> lower costs of operation will figure out that they can collectively reorg
> the last hour (or some time period) of the day overnight and this will be
> profitable. That's likely to cause the miners with more expensive
> operations to stop attempting mining the last hour of the day preemptively.
>
> What happens after that I'm not sure.
>

Miners will learn to create anyone-can-spend outputs to bribe other miners
to build on their block rather than reorg it.  (Due to the coinbase
maturity, this will require some amount of floating capital.)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

[Russell O'Connor via bitcoin-dev]

On Fri, May 13, 2022 at 5:43 PM Anthony Towns  wrote:

> For any specific opcode proposal, I think you still want to consider
>
>  1) how much you can do with it
>  2) how efficient it is to validate (and thus how cheap it is to use)
>  3) how easy it is to make it do what you want
>  4) how helpful it is at preventing bugs
>  5) how clean and maintainable the validation code is
>
> I guess to me CTV and APO are weakest at (1); CAT/CSFS falls down on
> (3) and (4); OP_TX is probably weakest at (5) and maybe not as good as
> we'd like at (3) and (4)?
>

FWIW, I think the rmain reasons to do CAT+CSFS is to validate oracle
messages and pubkey delegation.  The ability to covenants would be
secondary and would mostly serve to get us some real user data about what
sort of covenants users find especially valuable.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

[Russell O'Connor via bitcoin-dev]

On Wed, May 11, 2022 at 11:07 PM ZmnSCPxj  wrote:

> Good morning Russell,
>
> > On Wed, May 11, 2022 at 7:42 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > REMEMBER: `OP_CAT` BY ITSELF DOES NOT ENABLE COVENANTS, WHETHER
> RECURSIVE OR NOT.
> >
> >
> > I think the state of the art has advanced to the point where we can say
> "OP_CAT in tapscript enables non recursive covenants and it is unknown
> whether OP_CAT can enable recursive covenants or not".
> >
> > A. Poelstra in
> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html show
> how to use CAT to use the schnorr verification opcode to get the sighash
> value + 1 onto the stack, and then through some grinding and some more CAT,
> get the actual sighash value on the stack. From there we can use SHA256 to
> get the signed transaction data onto the stack and apply introspect (using
> CAT) to build functionality similar to OP_CTV.
> >
> > The missing bits for enabling recursive covenants comes down to needing
> to transform a scriptpubkey into an taproot address, which involves some
> tweaking. Poelstra has suggested that it might be possible to hijack the
> ECDSA checksig operation from a parallel, legacy input, in order to perform
> the calculations for this tweaking. But as far as I know no one has yet
> been able to achieve this feat.
>
> Hmm, I do not suppose it would have worked in ECDSA?
> Seems like this exploits linearity in the Schnorr.
> For the ECDSA case it seems that the trick in that link leads to `s = e +
> G[x]` where `G[x]` is the x-coordinate of `G`.
> (I am not a mathist, so I probably am not making sense; in particular,
> there may be an operation to add two SECP256K1 scalars that I am not aware
> of)
>
> In that case, since Schnorr was added later, I get away by a technicality,
> since it is not *just* `OP_CAT` which enabled this style of covenant, it
> was `OP_CAT` + BIP340 v(^^);
>

Correct.


> Also holy shit math is scary.
>
> Seems this also works with `OP_SUBSTR`, simply by inverting it into
> "validate that the concatenation is correct" rather than "concatenate it
> ourselves".
>
>
>
>
> So really: are recursive covenants good or...?
> Because if recursive covenants are good, what we should really work on is
> making them cheap (in CPU load/bandwidth load terms) and private, to avoid
> centralization and censoring.
>

My view is that recursive covenants are inevitable.  It is nearly
impossible to have programmable money without it because it is so difficult
to avoid.

Given that we cannot have programmable money without recursive covenants
and given all the considerations already discussed regarding them, i.e. no
worse than being compelled to co-sign transactions, and that user generated
addresses won't be encumbered by a covenant unless they specifically
generate it to be, I do think it makes sense to embrace them.


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

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

[Russell O'Connor via bitcoin-dev]

On Wed, May 11, 2022 at 7:42 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> REMEMBER: `OP_CAT` BY ITSELF DOES NOT ENABLE COVENANTS, WHETHER RECURSIVE
> OR NOT.
>

I think the state of the art has advanced to the point where we can say
"OP_CAT in tapscript enables non recursive covenants and it is unknown
whether OP_CAT can enable recursive covenants or not".

A. Poelstra in
https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html show
how to use CAT to use the schnorr verification opcode to get the sighash
value + 1 onto the stack, and then through some grinding and some more CAT,
get the actual sighash value on the stack.  From there we can use SHA256 to
get the signed transaction data onto the stack and apply introspect (using
CAT) to build functionality similar to OP_CTV.

The missing bits for enabling recursive covenants comes down to needing to
transform a scriptpubkey into an taproot address, which involves some
tweaking.  Poelstra has suggested that it might be possible to hijack the
ECDSA checksig operation from a parallel, legacy input, in order to perform
the calculations for this tweaking.  But as far as I know no one has yet
been able to achieve this feat.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Improving BIP 8 soft fork activation

[Russell O'Connor via bitcoin-dev]

Hi alicexbt,

As far as I understand things, I believe the whole notion of a MUST_SIGNAL
state is misguided today. Please correct me if I'm misunderstanding
something here.

Back when BIP8 was first proposed by Shaolin Fry, we were in a situation
where many existing clients waiting for segwit signalling had already been
deployed.  The purpose of mandatory signaling at that point in time was to
ensure all these existing clients would be activated together with any BIP8
clients.

However, if such other clients do not exist, the MUST_SIGNAL state no
longer accomplishes its purpose.  Going forward, I think there is little
reason to expect such other clients to exist alongside a BIP8 deployment.
If everyone uses a BIP8 deployment, then there are no other clients to
activate.  Alternatively, Speedy Trial was specifically designed to avoid
this parallel deployment for the reason that several people object to
allowing their client's non-BIP8 activation logic to be hijacked in this
manner.

Now I understand that some people would like *some* signal on the chain
that indicates a soft-fork activation in order to allow people who object
to the fork to make an "anti-fork" that rejects blocks containing the
soft-fork signal.  And while some sort of mandatory version bit signaling
*could* be used for this purpose, we do not *have* to use version bits.  We
also don't need such a signal span over multiple blocks.  Indeed, using
version bits and signaling over multiple blocks is quite bad because it
risks losing mining power if miners don't conform, or are unable to
conform, to the version bits signal.  (Recall at the time taproot's
signaling period started, the firmware needed for many miners to signal
version bits did not even exist yet!).

A soft-fork signal to enable an "anti-fork" only needs to be on a single
block and it can be almost anything.  For example we could have a signal
that at the block at lockin or perhaps the block at activation requires
that the coinbase must *not* contain the suffix "taproot sucks!".  This
suffices to prepare an "anti-fork" which would simply require that the
specified block must contain the suffix "taproot sucks!".

Anyway, I'm sure there are lots of design choices available better than a
MUST_SIGNAL state that does not risk potentially taking a large fraction of
mining hardware offline for a protracted period of time.

On Tue, May 10, 2022 at 10:02 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Bitcoin Developers,
>
> There were some disagreements with speedy trial activation method recently
> and BIP 8 became controversial because of LOT earlier. I have tried to
> solve these two problems after reading some arguments for/against different
> activation methods by removing LOT from BIP 8 and calculating MUST_SIGNAL
> state based on threshold reached.
>
> BIP draft with no code and some changes in BIP 8:
> https://gist.github.com/144bytes/5e58cad7ba9d9c1a7000d304920fe6f1
>
> State transitions diagram: https://i.imgur.com/dj4bFVK.png
>
> This proposal removes lockinontimeout flag, activation never fails
> although MUST_SIGNAL can be longer if miners signaling does not reach the
> threshold. Longer period for MUST_SIGNAL state is useful for coordination
> if LOCKED_IN was not reached.
>
> MUST_SIGNAL = ((100-t)/10)*2016 blocks, where t is threshold reached and
> blocks that fail to signal in MUST_SIGNAL phase are invalid.
>
> Example:
>
> - This activation method is used for a soft fork
> - Only 60% miners signaled readiness and timeout height was reached
> - MUST_SIGNAL phase starts and will last for 4*2016 blocks
> - LOCKED_IN and ACTIVE states remain same as BIP 8
> - Soft fork is activated with a delay of 2 months
>
>
> /dev/fd0
>
> Sent with ProtonMail  secure email.
> ___
> 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] What to do when contentious soft fork activations are attempted

[Russell O'Connor via bitcoin-dev]

On Fri, May 6, 2022 at 2:01 PM Jorge Timón via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Russell O'Connor wrote the definitive explanation for how ST arose in
>> the consensus process and how it was designed to make everyone
>> unhappy.  It's a great explanation of what we went through last year.
>>
>>   https://r6.ca/blog/20210615T191422Z.html
>>
>> "On Building Consensus and Speedy Trial"
>>
>> on | 2021-06-15T19:14:22Z
>> by | Russell O'Connor
>>
>
> That's a lot of text, are you sure he said in there he designed speedy
> trial to make everyone unhappy?
> Well, if we're still talking about it, that proves that it failed at its
> own design criterion of failing fast.
>

Quoting from https://r6.ca/blog/20210615T191422Z.html:

> Speedy Trial’s design is not based on any sort of activation philosophy
about failing fast.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Russell O'Connor via bitcoin-dev]

On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud  wrote:

> @Russel
> > the original MES vault .. commits to the destination address during
> unvaulting
>
> I see. Looking at the MES16 paper, OP_COV isn't described clearly enough
> for me to understand that it does that. However, I can imagine how it
> *might* do that.
>
> One possibility is that the intended destination is predetermined and
> hardcoded. This wouldn't be very useful, and also wouldn't be different
> than how CTV could do it, so I assume that isn't what you envisioned this
> doing.
>
> I can imagine instead that the definition of the pattern could be
> specified as a number indicating the number of stack items in the pattern,
> followed by that number of stack items. If that's how it is done, I can see
> the user inputting an intended destination script (corresponding to the
> intended destination address) which would then be somehow rotated in to the
> right spot within the pattern, allowing the pattern to specify the coins
> eventually reaching an address with that script. However, this could be
> quite cumbersome, and would require fully specifying the scripts along the
> covenant pathways leading to a fair amount of information duplication
> (since scripts must be specified both in the covenant and in spending the
> subsequent output). Both of these things would seem to make OP_COV in
> practice quite an expensive opcode to spend with. It also means that, since
> the transactor must fully specify the script, its not possible to take
> advantage of taproot's script hiding capabilities (were it to send to a
> taproot address).
>

So my understanding is that the COV proposal in MES lets you check that the
output's scriptPubKey matches the corresponding script item from the stack,
but the script item's value additionally allows some wildcard values.  In
particular, it makes use of the otherwise reserved opcodes OP_PUBKEY, and
OP_PUBKEYHASH as wildcards representing any, let's say, 32-byte or 20-byte
push value.

If you just used COV by itself, then these wildcards would be third-party
malleable, but you also have to sign the transaction with the hot wallet
key, which removes the malleability.

No need to rotate anything into place.

I hope this makes sense.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Russell O'Connor via bitcoin-dev]

Okay, Matt explained to me the intended application of CTV vaults off list,
so I have a better understanding now.

The CTV vault scheme is designed as an improvement over the traditional
management of hot-wallets and cold-wallets.  The CTV vault is logically on
the "cold-side" and lets funds be sent from the "cold" side to *one's own*
the hot wallet after the unvaulting delay.  In this case, the hot wallet
funds are always at risk, so it isn't unexpected that those funds could be
stolen.  After all, that is how hot wallets are today.  The advantage is
that funds can be moved from the "cold" side without needing to dig out the
cold keys.

The MES vault scheme applies to a different scenario.  In the MES case it
is the hot funds are inside the vault, and it is the hot key that unvaults
the funds and sends them to *customer's addresses* after a delay.  If the
hot-key is used in any unauthorised way, then funds can be sent to the
address of the cold key (the MES vault actually does something fancy in
case of recovery, but it could be adapted to simply send funds to a cold
wallet).

The MES vault lie somewhere between "better" and "different" when compared
to the CTV vault.  If one is unwilling to use the MES vault on the hot side
and have every withdrawl vetted, then, while you could use the MES design
on the cold side like the CTV vault, it wouldn't really offer you any
advantages over a CTV vault.  However, if you are interested in managing
all your payments through a vault (as I've been imagining) then the CTV
vault comes across as ineffective when compared to an MES style vault.

On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo 
wrote:

> Still trying to make sure I understand this concern, let me know if I get
> this all wrong.
>
> On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
> > It's not the attackers *only choice to succeed*.  If an attacker steals
> the hot key, then they have
> > the option to simply wait for the user to unvault their funds of their
> own accord and then race /
> > outspend the users transaction with their own.  Indeed, this is what we
> expect would happen in the
> > dark forest.
>
> Right, a key security assumption of the CTV-based vaults would be that you
> MUST NOT EVER withdraw
> more in one go than your hot wallet risk tolerance, but given that your
> attack isn't any worse than
> simply stealing the hot wallet key immediately after a withdraw.
>
> It does have the drawback that if you ever get a hot wallet key stole you
> have to rotate all of your
> CTV outputs and your CTV outputs must never be any larger than your hot
> wallet risk tolerance
> amount, both of which are somewhat frustrating limitations, but not
> security limitations, only
> practical ones.
>
> > And that's not even mentioning the issues already noted by the document
> regarding fee management,
> > which would likely also benefit from a less constrained design for
> covenants.
>
> Of course I've always been in favor of a less constrained covenants design
> from day one for ten
> reasons, but that's a whole other rabbit hole :)
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Russell O'Connor via bitcoin-dev]

On Sat, Apr 23, 2022 at 12:56 AM Billy Tetrud 
wrote:

> > If an attacker steals the hot key, then they have the option to simply
> wait for the user to unvault their funds
>
> This is definitely true. Its kind of a problem with most vault proposals.
> Its one of the primary reasons I designed an alternative proposal
> . The
> OP_BEFOREBLOCKVERIFY opcode I proposed solves this security hole by
> automatically swapping control of the UTXO over to the intended recipient
> after a timeout. Alternatively, if OP_BBV weren't available, OP_POS in
> conjunction with OP_CD could encode things such that the transaction
> with the hot key could only spend to the intended recipient.
>
> I'm curious if there are any other covenant proposals that have a solution
> to that problem. I'm not aware of any that do other than my proposal.
>

As I noted, the original MES vault
https://fc16.ifca.ai/bitcoin/papers/MES16.pdf, commits to the destination
address during unvaulting.  Their proposal uses CheckOutputVerify that
checks if a given output has a given amount and a given scriptPubKey.  (The
MES vault then goes on to add a PATTERN parameter to OP_COV's scriptPubKey
parameter in order to make a recursive vault, but that is used to deter
cold-key theft, not hot-key theft).

Our paper https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
impelments the MES vault in Elements (alpha) using CAT and
CHECKSIGFROMSTACK.  While I wouldn't necessarily call it a covenant
proposal, rather it is an observation that these opcodes happen to be
adequate for the task.

With such a big security caveat, I really don't find CTV vaults a
compelling example of using CTV.  Sure, if CTV happens to exist, by all
means do whatever you like.  But if anything, the CTV vault scheme instead
illustrates BlueMatt's point that we aren't really finished with covenant
research design yet:

Q: What ways can we build a secured vault that commits to the destination
address?
Q: Are there elegant ways of building secure vaults by using CTV plus
something else.  Presumably CAT + CTV would be enough, though maybe some
people are concerned that CAT might enable recursive covenants (if people
aren't willing to have even CAT, I don't see how we will ever really have
programmable money).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Russell O'Connor via bitcoin-dev]

On Fri, Apr 22, 2022 at 12:29 PM James O'Beirne via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This vault design (https://github.com/jamesob/simple-ctv-vault)
> is a good benchmark for evaluating covenant proposals because it's (i)
> simple and (ii) has high utility for many users of Bitcoin. I would
> love to see it implemented in one or all of these alternatives, but I
> am almost certain no one will do it in the next few months because the
> implementations, tooling, and in some cases even complete
> specifications do not exist.
>

Quoting from the link above:
Detecting theft

This unvault step is critical because it allows us to detect unexpected
behavior. If an attacker had stolen our hot wallet keys, their only choice
to succeed in the theft is to trigger an unvault.


It's not the attackers *only choice to succeed*.  If an attacker steals the
hot key, then they have the option to simply wait for the user to unvault
their funds of their own accord and then race / outspend the users
transaction with their own.  Indeed, this is what we expect would happen in
the dark forest.

A key feature of the MES vault design is that the destination address is
included, and committed to, by the unvaulting step.  However, this can only
be achieved with a less constrained design for covenants.

I suppose I can see that the damage from a hot key theft could be more
contained under some circumstances using a CTV vault, but let us not
overstate the value of the CTV vault.

And that's not even mentioning the issues already noted by the document
regarding fee management, which would likely also benefit from a less
constrained design for covenants.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV Signet Parameters

[Russell O'Connor via bitcoin-dev]

On Thu, Apr 21, 2022 at 1:04 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>  - is there really any benefit to doing it as a NOP vs a taproot-only
>opcode like TXHASH? Theoretically, sure, that saves some bytes; but as
>was pointed out on #bitcoin-wizards the other day, you can't express
>those outputs as an address, which makes them not very interoperable,
>and if they're not interoperable between, say, an exchange and its
>users trying to do a withdraw, how useful is that really ever going
>to be?
>

FWIW, this is also approximately where my sticking point lies with BIP-119.

Overall I've come around to the idea of something like CTV.  The ability to
construct "smart contracts" that commit to *multiple* possible payout
schemes based on some conditions seems like a very useful construct, and
there have been several examples of  schemes proposed that use this feature.

However, I'm still skeptical of the bare-CTV part of BIP-119 (and I'm told
that bare-CTV hasn't even appeared on the CTV signet).  Unlike the general
smart-contracting case, bare-CTV does not have any branches.  All it can do
is commit to a subsequent transaction's outputs.  At first glance this
appears to be a waste because, for less bandwidth, that transaction could
just realize those outputs immediately, so why would anyone want to delay
the inevitable?

One reason might be that you want to commit to the output early during a
high-fee time, and then complete the transaction later during a low-fee
time.  While there are fee-rate situations where this could result in lower
fees than committing to the outputs all at once, it would be even cheaper
still to just wait to do the payout at the low-fee time.  I'm struggling to
understand the advantages of the advanced commitment, along with all the
overhead that entails.  Doesn't it just cause more blockspace to be used
overall?

There are some other proposed use cases for bare-CTV.  A bare-CTV can be
used to delay a "trigger"-transaction.  Some contracts, such as vaults, use
a relative-locktime as part of their construction and it could make sense
to make an output commitment but not realize those outputs yet until you
are ready to start your relative-time lock clock.  But bare-CTV doesn't
support any co-signing ability here, so you are relying entirely on keeping
the transaction data secret to prevent a third-party from triggering your
relative-lock clock.  More specifically for a vault scheme, since
bare-CTV's are currently unaddressable, and AFAIK, there is no address
format proposal yet, it is impossible to receive funds directly into a
vault.  You must shuffle received funds into your vault yourself, which
seems very likely to negate the cost savings of using bare-CTV in the first
place (please correct me if I'm wrong).  Better to receive funds directly
into a taproot-CTV vault, which has an address, and while you are at it,
you could place the cold-key as the taproot key to save even more when
using the cold-key to move vault funds.

There might be even more exotic use cases of bare-CTV.  For example you
could commit to a transaction that has a second input that doesn't yet
exist in the UTXO set in an attempt to coax it into existence. I don't know
if there have been any proposals to take advantage of this.

With that said, everything that bare-CTV can do, can also be done by
tapscript-CTV; so it is just a matter of cost.  I'm struggling to
understand where this cost savings is and how much those savings are going
to be given that bare-CTV is unaddressable and seems to ultimately occupy
more-blockspace than if the outputs were directly committed to.

I also believe the bare-CTV question is material, because if bare-CTV were
not part of the spec, then I'd be advocating for using an OP_SUCCESS code
from tapscript instead, and either use push-style semantics for CTV, which
would be composed with EQUAL_VERIFY to mimic the currently proposed
verification style-semantics, or a hybrid push-or-verify semantics that
would either push or verify depending on the size of the input.  (And I
still think a more general TXHASH would be even better, though if I cannot
convince aj then perhaps I'm wrong.)

I'm not saying bare-CTV is necessarily a bad idea.  I'm just struggling
with its justification.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

[Russell O'Connor via bitcoin-dev]

Thanks for the clarification.

You don't think referring to the microcode via its hash, effectively using
32-byte encoding of opcodes, is still rather long winded?

On Tue, Mar 22, 2022 at 12:23 PM ZmnSCPxj  wrote:

> Good morning Russell,
>
> > Setting aside my thoughts that something like Simplicity would make a
> better platform than Bitcoin Script (due to expression operating on a more
> narrow interface than the entire stack (I'm looking at you OP_DEPTH)) there
> is an issue with namespace management.
> >
> > If I understand correctly, your implication was that once opcodes are
> redefined by an OP_RETURN transaction, subsequent transactions of that
> opcode refer to the new microtransaction.  But then we have a race
> condition between people submitting transactions expecting the outputs to
> refer to the old code and having their code redefined by the time they do
> get confirmed  (or worse having them reorged).
>
> No, use of specific microcodes is opt-in: you have to use a specific
> `0xce` Tapscript version, ***and*** refer to the microcode you want to use
> via the hash of the microcode.
>
> The only race condition is reorging out a newly-defined microcode.
> This can be avoided by waiting for deep confirmation of a newly-defined
> microcode before actually using it.
>
> But once the microcode introduction outpoint of a particular microcode has
> been deeply confirmed, then your Tapscript can refer to the microcode, and
> its meaning does not change.
>
> Fullnodes may need to maintain multiple microcodes, which is why creating
> new microcodes is expensive; they not only require JIT compilation, they
> also require that fullnodes keep an index that cannot have items deleted.
>
>
> The advantage of the microcode scheme is that the size of the SCRIPT can
> be used as a proxy for CPU load  just as it is done for current Bitcoin
> SCRIPT.
> As long as the number of `UOP_` micro-opcodes that an `OP_` code can
> expand to is bounded, and we avoid looping constructs, then the CPU load is
> also bounded and the size of the SCRIPT approximates the amount of
> processing needed, thus microcode does not require a softfork to modify
> weight calculations in the future.
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

[Russell O'Connor via bitcoin-dev]

Setting aside my thoughts that something like Simplicity would make a
better platform than Bitcoin Script (due to expression operating on a more
narrow interface than the entire stack (I'm looking at you OP_DEPTH)) there
is an issue with namespace management.

If I understand correctly, your implication was that once opcodes are
redefined by an OP_RETURN transaction, subsequent transactions of that
opcode refer to the new microtransaction.  But then we have a race
condition between people submitting transactions expecting the outputs to
refer to the old code and having their code redefined by the time they do
get confirmed  (or worse having them reorged).

I've partially addressed this issue in my Simplicity design where the
commitment of a Simplicity program in a scriptpubkey covers the hash of the
specification of the jets used, which makes commits unambiguously to the
semantics (rightly or wrongly).  But the issue resurfaces at redemption
time where I (currently) have a consensus critical map of codes to jets
that is used to decode the witness data into a Simplicity program.  If one
were to allow this map of codes to jets to be replaced (rather than just
extended) then it would cause redemption to fail, because the hash of the
new jets would no longer match the hash of the jets appearing the the
input's scriptpubkey commitment.  While this is still not good and I don't
recommend it, it is probably better than letting the semantics of your
programs be changed out from under you.

This comment is not meant as an endorsement of ths idea, which is a little
bit out there, at least as far as Bitcoin is concerned. :)

My long term plans are to move this consensus critical map of codes out of
the consensus layer and into the p2p layer where peers can negotiate their
own encodings between each other.  But that plan is also a little bit out
there, and it still doesn't solve the issue of how to weight reused jets,
where weight is still consensus critical.

On Tue, Mar 22, 2022 at 1:37 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning list,
>
> It is entirely possible that I have gotten into the deep end and am now
> drowning in insanity, but here goes
>
> Subject: Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks
>
> Introduction
> 
>
> Recent (Early 2022) discussions on the bitcoin-dev mailing
> list have largely focused on new constructs that enable new
> functionality.
>
> One general idea can be summarized this way:
>
> * We should provide a very general language.
>   * Then later, once we have learned how to use this language,
> we can softfork in new opcodes that compress sections of
> programs written in this general language.
>
> There are two arguments against this style:
>
> 1.  One of the most powerful arguments the "general" side of
> the "general v specific" debate is that softforks are
> painful because people are going to keep reiterating the
> activation parameters debate in a memoryless process, so
> we want to keep the number of softforks low.
> * So, we should just provide a very general language and
>   never softfork in any other change ever again.
> 2.  One of the most powerful arguments the "general" side of
> the "general v specific" debate is that softforks are
> painful because people are going to keep reiterating the
> activation parameters debate in a memoryless process, so
> we want to keep the number of softforks low.
> * So, we should just skip over the initial very general
>   language and individually activate small, specific
>   constructs, reducing the needed softforks by one.
>
> By taking a page from microprocessor design, it seems to me
> that we can use the same above general idea (a general base
> language where we later "bless" some sequence of operations)
> while avoiding some of the arguments against it.
>
> Digression: Microcodes In CISC Microprocessors
> --
>
> In the 1980s and 1990s, two competing microprocessor design
> paradigms arose:
>
> * Complex Instruction Set Computing (CISC)
>   - Few registers, many addressing/indexing modes, variable
> instruction length, many obscure instructions.
> * Reduced Instruction Set Computing (RISC)
>   - Many registers, usually only immediate and indexed
> addressing modes, fixed instruction length, few
> instructions.
>
> In CISC, the microprocessor provides very application-specific
> instructions, often with a small number of registers with
> specific uses.
> The instruction set was complicated, and often required
> multiple specific circuits for each application-specific
> instruction.
> Instructions had varying sizes and varying number of cycles.
>
> In RISC, the micrprocessor provides fewer instructions, and
> programmers (or compilers) are supposed to generate the code
> for all application-specific needs.
> The processor provided large 

Re: [bitcoin-dev] Speedy Trial

[Russell O'Connor via bitcoin-dev]

On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón  wrote:

>
> A major contender to the Speedy Trial design at the time was to mandate
>> eventual forced signalling, championed by luke-jr.  It turns out that, at
>> the time of that proposal, a large amount of hash power simply did not have
>> the firmware required to support signalling.  That activation proposal
>> never got broad consensus, and rightly so, because in retrospect we see
>> that the design might have risked knocking a significant fraction of mining
>> power offline if it had been deployed.  Imagine if the firmware couldn't be
>> quickly updated or imagine if the problem had been hardware related.
>>
>
>>> Yes, I like this solution too, with a little caveat: an easy mechanism
>>> for users to actively oppose a proposal.
>>> Luke alao talked about this.
>>> If users oppose, they should use activation as a trigger to fork out of
>>> the network by invalidating the block that produces activation.
>>> The bad scenario here is that miners want to deploy something but users
>>> don't want to.
>>> "But that may lead to a fork". Yeah, I know.
>>> I hope imagining a scenario in which developers propose something that
>>> most miners accept but some users reject is not taboo.
>>>
>>
>> This topic is not taboo.
>>
>> There are a couple of ways of opting out of taproot.  Firstly, users can
>> just not use taproot.  Secondly, users can choose to not enforce taproot
>> either by running an older version of Bitcoin Core or otherwise forking the
>> source code.  Thirdly, if some users insist on a chain where taproot is
>> "not activated", they can always softk-fork in their own rule that
>> disallows the version bits that complete the Speedy Trial activation
>> sequence, or alternatively soft-fork in a rule to make spending from (or
>> to) taproot addresses illegal.
>>
>
> Since it's about activation in general and not about taproot specifically,
> your third point is the one that applies.
> Users could have coordinated to have "activation x" never activated in
> their chains if they simply make a rule that activating a given proposal
> (with bip8) is forbidden in their chain.
> But coordination requires time.
>

A mechanism of soft-forking against activation exists.  What more do you
want? Are we supposed to write the code on behalf of this hypothetical
group of users who may or may not exist for them just so that they can have
a node that remains stalled on Speedy Trial lockin?  That simply isn't
reasonable, but if you think it is, I invite you to create such a fork.


> Please, try to imagine an example for an activation that you wouldn't like
> yourself. Imagine it gets proposed and you, as a user, want to resist it.
>

If I believe I'm in the economic majority then I'll just refuse to upgrade
my node, which was option 2. I don't know why you dismissed it.

Not much can prevent a miner cartel from enforcing rules that users don't
want other than hard forking a replacement POW.  There is no effective
difference between some developers releasing a malicious soft-fork of
Bitcoin and the miners releasing a malicious version themselves.  And when
the miner cartel forms, they aren't necessarily going to be polite enough
to give a transparent signal of their new rules.  However, without the
economic majority enforcing their set of rules, the cartel continuously
risks falling apart from the temptation of transaction fees of the censored
transactions.

On the other hand, If I find out I'm in the economic minority then I have
little choice but to either accept the existence of the new rules or sell
my Bitcoin.  Look, you cannot have the perfect system of money all by your
lonesome self.  Money doesn't have economic value if no one else wants to
trade you for it.  Just ask that poor user who YOLO'd his own taproot
activation in advance all by themselves.  I'm sure they think they've got
just the perfect money system, with taproot early and everything.  But now
their node is stuck at block 692261
 and hasn't made
progress since.  No doubt they are hunkered down for the long term,
absolutely committed to their fork and just waiting for the rest of the
world to come around to how much better their version of Bitcoin is than
the rest of us.

Even though you've dismissed it, one of the considerations of taproot was
that it is opt-in for users to use the functionality.  Future soft-forks
ought to have the same considerations to the extent possible.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Russell O'Connor via bitcoin-dev]

On Fri, Mar 11, 2022 at 7:18 AM Jorge Timón  wrote:

> I talked about this. But the "no-divergent-rules" faction doesn't like it,
> so we can pretend we have listened to this "faction" and addressed all its
> concerns, I guess.
> Or perhaps it's just "prosectution complex", but, hey, what do I know
> about psychology?
>

Your accusations of bad faith on the part of myself and pretty much
everyone else makes me disinclined to continue this discussion with you.
I'll reply, but if you want me to continue beyond this, then you need to
knock it off with the accusations.


> A major contender to the Speedy Trial design at the time was to mandate
>> eventual forced signalling, championed by luke-jr.  It turns out that, at
>> the time of that proposal, a large amount of hash power simply did not have
>> the firmware required to support signalling.  That activation proposal
>> never got broad consensus, and rightly so, because in retrospect we see
>> that the design might have risked knocking a significant fraction of mining
>> power offline if it had been deployed.  Imagine if the firmware couldn't be
>> quickly updated or imagine if the problem had been hardware related.
>>
>
> Yes, I like this solution too, with a little caveat: an easy mechanism for
> users to actively oppose a proposal.
> Luke alao talked about this.
> If users oppose, they should use activation as a trigger to fork out of
> the network by invalidating the block that produces activation.
> The bad scenario here is that miners want to deploy something but users
> don't want to.
> "But that may lead to a fork". Yeah, I know.
> I hope imagining a scenario in which developers propose something that
> most miners accept but some users reject is not taboo.
>

This topic is not taboo.

There are a couple of ways of opting out of taproot.  Firstly, users can
just not use taproot.  Secondly, users can choose to not enforce taproot
either by running an older version of Bitcoin Core or otherwise forking the
source code.  Thirdly, if some users insist on a chain where taproot is
"not activated", they can always softk-fork in their own rule that
disallows the version bits that complete the Speedy Trial activation
sequence, or alternatively soft-fork in a rule to make spending from (or
to) taproot addresses illegal.

As for mark, he wasn't talking about activation, but quantum computing
> concerns. Perhaps those have been "addressed"?
> I just don't know where.
>

Quantum concerns were discussed.  Working from memory, the arguments were
(1) If you are worried about your funds not being secured by taproot, then
don't use taproot addresses, and (2) If you are worried about everyone
else's funds not being quantum secure by other people choosing to use
taproot, well it is already too late because over 5M BTC is currently
quantum insecure due to pubkey reuse <
https://nitter.net/pwuille/status/1108091924404027392>.  I think it is
unlikely that a quantum breakthrough will sneak up on us without time to
address the issue and, at the very least, warn people to move their funds
off of taproot and other reused addresses, if not forking in some quantum
secure alternative.  A recent paper <
https://www.sussex.ac.uk/physics/iqt/wp-content/uploads/2022/01/Webber-2022.pdf>
suggest that millions physical qubits will be needed to break EC in a day
with current error correction technology.  But even if taproot were to be
very suddenly banned, there is still a small possibility for recovery
because one can prove ownership of HD pubkeys by providing a zero-knowledge
proof of the chaincode used to derive them.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Speedy Trial

[Russell O'Connor via bitcoin-dev]

On Thu., Mar. 10, 2022, 08:04 Jorge Timón via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> You're right, we shouldn't get personal. We shouldn't ignore feedback from
> me, mark friedenbach or luke just because of who it comes from.
>

For goodness sake Jorge, enough with the persecution complex.

As the person who initially proposed the Speedy Trial deployment design, I
can say it was designed to take in account those concerns raised by luke-jr
and the "no-miner-veto" faction.  I also listened to the
"devs-do-not-decide" faction and the "no-divegent-consensus-rules" faction
and their concerns.

The "no-miner-veto" concerns are, to an extent, addressed by the short
timeline of Speedy Trial.  No more waiting 2 years on the miners dragging
their feet.  If ST fails to active then we are back where we started with
at most a few weeks lost.  And those weeks aren't really lost if they would
have been wasted away anyways trying to find broad consensus on another
deployment mechanism.

I get that you don't like the design of Speedy Trial.  You may even object
that it fails to really address your concerns by leaving open how to follow
up a failed Speedy Trial deployment.  But regardless of how you feel, I
believe I did meaningfully address the those miner-veto concerns and other
people agree with me.

If you are so concerned about listening to legitimate criticism, maybe you
can design a new deployment mechanism that addresses the concerns of the
"devs-do-not-decide" faction and the "no-divegent-consensus-rules"
faction.  Or do you feel that their concerns are illegitimate?  Maybe, by
sheer coincidence, all people you disagree with have illegitimate concerns
while only your concerns are legitimate.

A major contender to the Speedy Trial design at the time was to mandate
eventual forced signalling, championed by luke-jr.  It turns out that, at
the time of that proposal, a large amount of hash power simply did not have
the firmware required to support signalling.  That activation proposal
never got broad consensus, and rightly so, because in retrospect we see
that the design might have risked knocking a significant fraction of mining
power offline if it had been deployed.  Imagine if the firmware couldn't be
quickly updated or imagine if the problem had been hardware related.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin scripting and lisp

[Russell O'Connor via bitcoin-dev]

The circuit generated from Simplicity was larger than the hand made one.

On Sat, Mar 5, 2022 at 6:20 PM ZmnSCPxj  wrote:

> Good morning Russell,
>
> > On Sat, Mar 5, 2022 at 8:41 AM Jeremy Rubin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > It seems like a decent concept for exploration.
> > >
> > > AJ, I'd be interested to know what you've been able to build with Chia
> Lisp and what your experience has been... e.g. what does the Lightning
> Network look like on Chia?
> > >
> > > One question that I have had is that it seems like to me that neither
> simplicity nor chia lisp would be particularly suited to a ZK prover...
> >
> > Not that I necessarily disagree with this statement, but I can say that
> I have experimented with compiling Simplicity to Boolean circuits.  It was
> a while ago, but I think the result of compiling my SHA256 program was
> within an order of magnitude of the hand made SHA256 circuit for
> bulletproofs.
>
> "Within" can mean "larger" or "smaller" in this context, which was it?
> From what I understand, compilers for ZK-provable circuits are still not
> as effective as humans, so I would assume "larger", but I would be much
> interested if it is "smaller"!
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin scripting and lisp

[Russell O'Connor via bitcoin-dev]

On Sat, Mar 5, 2022 at 8:41 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> It seems like a decent concept for exploration.
>
> AJ, I'd be interested to know what you've been able to build with Chia
> Lisp and what your experience has been... e.g. what does the Lightning
> Network look like on Chia?
>
>
> One question that I have had is that it seems like to me that neither
> simplicity nor chia lisp would be particularly suited to a ZK prover...
>

Not that I necessarily disagree with this statement, but I can say that I
have experimented with compiling Simplicity to Boolean circuits.  It was a
while ago, but I think the result of compiling my SHA256 program was within
an order of magnitude of the hand made SHA256 circuit for bulletproofs.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

On Thu, Feb 17, 2022 at 9:27 AM Anthony Towns  wrote:

>
> I guess that's all partly dependent on thinking that, TXHASH isn't
> great for tx introspection (especially without CAT) and, (without tx
> introspection and decent math opcodes), DLCs already provide all the
> interesting oracle behaviour you're really going to get...
>

You left out CSFSV's ability to do pubkey delegation.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

On Tue, Feb 15, 2022 at 10:45 PM Rusty Russell 
wrote:

> Jeremy Rubin  writes:
> > Hi Rusty,
> >
> > Please see my post in the other email thread
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html
> >
> > The differences in this regard are several, and worth understanding
> beyond
> > "you can iterate CTV". I'd note a few clear examples for showing that
> "CTV
> > is just as powerful" is not a valid claim:
> >
> > 1) CTV requires the contract to be fully enumerated and is non-recursive.
> > For example, a simple contract that allows n participants to take an
> action
> > in any order requires factorially many pre-computations, not just linear
> or
> > constant. For reference, 24! is about 2**80. Whereas for a more
> > interpretive covenant -- which is often introduced with the features for
> > recursion -- you can compute the programs for these addresses in constant
> > time.
> > 2) CTV requires the contract to be fully enumerated: For example, a
> simple
> > contract one could write is "Output 0 script matches Output 1", and the
> set
> > of outcomes is again unbounded a-priori. With CTV you need to know the
> set
> > of pairs you'd like to be able to expand to a-priori
> > 3) Combining 1 and 2, you could imagine recursing on an open-ended thing
> > like creating many identical outputs over time but not constraining what
> > those outputs are. E.g., Output 0 matches Input 0, Output 1 matches
> Output
> > 2.
>
> Oh agreed.  It was distinction of "recursive" vs "not recursive" which
> was less useful in this context.
>
> "limited to complete enumeration" is the more useful distinction: it's a
> bright line between CTV and TXHASH IMHO.
>

If TXHASH is limited to requiring the flags be included in the hash (as is
done with sighash) I believe TXHASH has the same "up front" nature that CTV
has.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Thoughts on fee bumping

[Russell O'Connor via bitcoin-dev]

> >> 2. (from Suhas) "once a valid transaction is created, it should not
> become invalid later on unless the inputs are double-spent."
> > This doesn't seem like a huge concern to me
>
> I agree that this shouldn't be a concern. In fact, I've asked numerous
> people in numerous places what practical downside there is to transactions
> that become invalid, and I've heard basically radio silence other than one
> off hand remark by satoshi at the dawn of time which didn't seem to me to
> have good reasoning. I haven't seen any downside whatsoever of transactions
> that can become invalid for anyone waiting the standard 6 confirmations -
> the reorg risks only exists for people not waiting for standard
> finalization. So I don't think we should consider that aspect of a
> sponsorship transaction that can only be mined with the transaction it
> sponsors to be a problem unless a specific practical problem case can be
> identified. Even if a significant such case was identified, an easy
> solution would be to simply allow sponsorship transactions to be mined on
> or after the sponsored transaction is mined.
>

The downside is that in a 6 block reorg any transaction that is moved past
its expiration date becomes invalid and all its descendants become invalid
too.

The current consensus threshold for transactions to become invalid is a 100
block reorg, and I see no reason to change this threshold.  I promise to
personally build a wallet that always creates transactions on the verge of
becoming invalid should anyone ever implement a feature that violates this
tx validity principle.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

On Tue, Feb 15, 2022 at 1:57 PM Jeremy Rubin 
wrote:

> Hi Rusty,
>
> Please see my post in the other email thread
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html
>
> The differences in this regard are several, and worth understanding beyond
> "you can iterate CTV". I'd note a few clear examples for showing that "CTV
> is just as powerful" is not a valid claim:
>
> 1) CTV requires the contract to be fully enumerated and is non-recursive.
> For example, a simple contract that allows n participants to take an action
> in any order requires factorially many pre-computations, not just linear or
> constant. For reference, 24! is about 2**80. Whereas for a more
> interpretive covenant -- which is often introduced with the features for
> recursion -- you can compute the programs for these addresses in constant
> time.
> 2) CTV requires the contract to be fully enumerated: For example, a simple
> contract one could write is "Output 0 script matches Output 1", and the set
> of outcomes is again unbounded a-priori. With CTV you need to know the set
> of pairs you'd like to be able to expand to a-priori
> 3) Combining 1 and 2, you could imagine recursing on an open-ended thing
> like creating many identical outputs over time but not constraining what
> those outputs are. E.g., Output 0 matches Input 0, Output 1 matches Output
> 2.
>
> I think for your point the inverse seems to hold: for the limited
> situations we might want to set up, CTV often ends up being sufficient
> because usually we can enumerate all the possible outcomes we'd like (or at
> least find a mapping onto such a construction). CTV is indeed very
> powerful, but as I demonstrated above, not powerful in the same way
> ("Complexity Class") that OP_TX or TXHASH might be.
>

Just to be clear, if OP_TXHASH is restricted to including the flags for the
values to be hashed (at least for OP_TXHASH0), we don't appear to enter
recursive covenant territory, as long as we remain without OP_CAT.


> At the very least we should clearly understand *what* and *why* we are
> advocating for more sophisticated designs and have a thorough understanding
> of the protocol complexity we are motivated to introduce the expanded
> functionality. Further, if one advocates for TX/TXHASH on a featureful
> basis, it's at least a technical ACK on the functionality CTV is
> introducing (as it is a subset) and perhaps a disagreement on project
> management, which I think is worth noting. There is a very wide gap between
> "X is unsafe" and "I prefer Y which X is a subset of ''.
>

I'm certainly of the opinion we should have some feature to enable the
commitment of outputs.  It seems quite useful in various protocols.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

On Mon, Jan 31, 2022 at 8:16 PM Anthony Towns  wrote:

> On Fri, Jan 28, 2022 at 08:56:25AM -0500, Russell O'Connor via bitcoin-dev
> wrote:
> > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
> > For more complex interactions, I was imagining combining this TXHASH
> > proposal with CAT and/or rolling SHA256 opcodes.  If TXHASH ended up
> > supporting relative or absolute input/output indexes then users could
> > assemble the hashes of the particular inputs and outputs they care about
> > into a single signed message.
>
> That's certainly possible, but it sure seems overly complicated and
> error prone...
>

Indeed, and we really want something that can be programmed at redemption
time.
That probably involves something like how the historic MULTISIG worked by
having list of input / output indexes be passed in along with length
arguments.

I don't think there will be problems with quadratic hashing here because as
more inputs are list, the witness in turns grows larger itself.  The amount
of stack elements that can be copied is limited by a constant (3DUP).
Certainly care is needed here, but also keep in mind that an OP_HASH256
does a double hash and costs one weight unit.

That said, your SIGHASH_GROUP proposal suggests that some sort of
intra-input communication is really needed, and that is something I would
need to think about.

While normally I'd be hesitant about this sort of feature creep, when we
are talking about doing soft-forks, I really think it makes sense to think
through these sorts of issues (as we are doing here).


> > I don't think there is much in the way of lessons to be drawn from how we
> > see Bitcoin Script used today with regards to programs built out of
> > reusable components.
>
> I guess I think one conclusion we should draw is some modesty in how
> good we are at creating general reusable components. That is, bitcoin
> script looks a lot like a relatively general expression language,
> that should allow you to write interesting things; but in practice a
> lot of it was buggy (OP_VER hardforks and resource exhaustion issues),
> or not powerful enough to actually be interesting, or too complicated
> to actually get enough use out of [0].
>

> TXHASH + CSFSV won't be enough by itself to allow for very interesting
> > programs Bitcoin Script yet, we still need CAT and friends for that,
>
> "CAT" and "CHECKSIGFROMSTACK" are both things that have been available in
> elements for a while; has anyone managed to build anything interesting
> with them in practice, or are they only useful for thought experiments
> and blog posts? To me, that suggests that while they're useful for
> theoretical discussion, they don't turn out to be a good design in
> practice.
>

Perhaps the lesson to be drawn is that languages should support multiplying
two numbers together.

Having 2/3rd of the language you need to write interesting programs doesn't
mean that you get 2/3rd of the interesting programs written.

But beyond that, there is a lot more to a smart contract than just the
Script.  Dmitry Petukhov has a fleshed out design for Asset based lending
on liquid at https://ruggedbytes.com/articles/ll/, despite the limitations
of (pre-taproot) Elements Script.  But to make it a real thing you need
infrastructure for working with partial transactions, key management, etc.

> but
> > CSFSV is at least a step in that direction.  CSFSV can take arbitrary
> > messages and these messages can be fixed strings, or they can be hashes
> of
> > strings (that need to be revealed), or they can be hashes returned from
> > TXHASH, or they can be locktime values, or they can be values that are
> > added or subtracted from locktime values, or they can be values used for
> > thresholds, or they can be other pubkeys for delegation purposes, or they
> > can be other signatures ... for who knows what purpose.
>
> I mean, if you can't even think of a couple of uses, that doesn't seem
> very interesting to pursue in the near term? CTV has something like half
> a dozen fairly near-term use cases, but obviously those can all be done
> just with TXHASH without a need for CSFS, and likewise all the ANYPREVOUT
> things can obviously be done via CHECKSIG without either TXHASH or CSFS...
>
> To me, the point of having CSFS (as opposed to CHECKSIG) seems to be
> verifying that an oracle asserted something; but for really simply boolean
> decisions, doing that via a DLC seems better in general since that moves
> more of the work off-chain; and for the case where the signature is being
> used to authenticate input into the script rather than just gating a path,
> that feels a bit like a weaker version of graftroot?
>

I didn't really mean this as a list of app

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

The hash would normally also cover the hash flags in use, and would be
different in those two cases.

But yes, it seems at the last minute I did include a suggestion to disable
covering the flag themselves in the hash and appear to have accidentally
allowed for recursive covenants (a common occurrence when designing
opcodes).

On Sat, Jan 29, 2022 at 12:01 PM Jeremy Rubin  wrote:

>
>
>
>> Perhaps there is some misunderstanding.  TXHASH + CSFSV doesn't allow for
>> complex or recursive covenants.  Typically CAT is needed, at minimum, to
>> create those sorts of things.  TXHASH still amounts to deploying a
>> non-recursive covenant construction.
>>
>>
> This seems false to me.
>
>  txhash  scriptpubkey> txhash equalverify
>
> Is that not a recursive covenant? With a little extra work you can also
> control for amounts and stuff.
>
>
>
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

On Fri, Jan 28, 2022 at 10:14 AM James O'Beirne 
wrote:

> > Technical debt isn't a measure of weight of transactions.
>
> Sorry, my original sentence was a little unclear. I meant to say that the
> notion that CTV is just a subpar waypoint en route to a more general
> covenant system may not be accurate if it is a more efficient way (in terms
> of chainstate/weight) to express highly useful patterns like vaults. In
> that case, characterizing CTV as technical debt wouldn't be right.
>

It only costs a few more weight units, on the order of 2 or 3, to use
TXHASH in place of CTV.  Notably, the reverse, using CTV in place of
TXHASH, is much more expensive, requiring more than 32 weight units.


> > Our only option here is to be mindful of the long term implications of
> the design choices we are making today.
>
> Your points are well taken - I don't think anyone is arguing against
> thinking hard about consensus changes. But I have yet to see a proposal for
> covenants that is as efficient on-chain and easy to reason about as CTV is.
>
> I also think there's some value in "legging into" covenants by deploying a
> simple, non-recursive construction like CTV that services some very
> important uses, and then taking as much time as necessary to think about
> how to solve more existential problems, like UTXO scalability, that likely
> require a recursive covenant construction.
>
> There doesn't have to be mutual exclusion in the approaches, especially
> when the maintenance burden of CTV seems to be so low. If we end up
> deploying something that requires a wider variety of in-script hashing, it
> seems likely that CTV's hash will be able to "free ride" on whatever more
> general sighash cache structure we come up with.
>

Perhaps there is some misunderstanding.  TXHASH + CSFSV doesn't allow for
complex or recursive covenants.  Typically CAT is needed, at minimum, to
create those sorts of things.  TXHASH still amounts to deploying a
non-recursive covenant construction.

With regards to CTV, in short my primary criticisms are (1) Push semantics
is preferable to verify semantics, because simulating verify semantics from
push is cheap, while simulating push semantics from verify is not
particularly cheap.
And (2) given Push semantics we ought to have parameters to support both
CTV-style hashes and APO-style hashes (which in the presence of CSFSV gives
us APO applications), and, while we are at it, as many other style hashes
as we can reasonably devise so we don't have to go through yet another
soft-fork process every time someone comes up with a new subset of
transaction data they would like to be hashed for their application.

I understand why CTV was designed with verify semantics: it would like to
be NOP compatible.  That certainly made sense pre-tapscript.  I just
haven't (yet) found the use cases for that compatibility to be compelling
in a post-tapscript world.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

On Thu, Jan 27, 2022 at 7:19 PM James O'Beirne 
wrote:

> > I don't think implementing a CTV opcode that we expect to largely be
> obsoleted by a TXHASH at a later date is yielding good value from a soft
> fork process.
>
> This presumes the eventual adoption of TXHASH (or something like it).
> You're presenting a novel idea that, as far as I know, hasn't had much time
> to bake in public. Like Jeremy, I'm concerned by the combinatorial growth
> of flags and the implications that has for testing. Caching for something
> like TXHASH looks to me like a whole different ballgame relative to CTV,
> which has a single kind of hash.
>

Let's not overstate the concern around the combinatorics of TXHASH.   It's
not like there is a vast amount of cross-flag interaction we are talking
about here.  There are also a combinatorial number of ways of assembling
opcodes in Bitcoin script, but we aren't required to exhaustively test
every single possible Script program.


> Even if we were to adopt something like TXHASH, how long is it going to
> take to develop, test, and release? My guess is "a while" - in the
> meantime, users of Bitcoin are without a vault strategy that doesn't
> require either presigning transactions with ephemeral keys (operationally
> difficult) or multisig configurations that would make Rube Goldberg blush
> (operationally difficult and precarious). The utility of vaulting seems
> underappreciated among consensus devs and it's something I'd like to write
> about soon in a separate post.
>
> > The strongest argument I can make in favour of CTV would be something
> like: "We definitely want bare CTV and if we are going to add CTV to legacy
> script (since we cannot use TXHASH in legacy script), then it is actually
> easier not to exclude it from tapscript, even if we plan to add TXHASH to
> tapscript as well."
>
> Another argument for CTV (which I find especially persuasive) is its
> simplicity - it's relatively easy to reason about and, at this point,
> pretty well understood. It seems like a low-risk change relative to some of
> the other covenant proposals, nearly all of which elicit a good deal of
> headscratching (at least from me) and seem to require not only larger
> on-chain footprints but sizable code changes.
>


> > I am sensitive to technical debt and soft fork processes
>

> If OP_CTV ends up being the most practical approach for vaulting - among
> other things - in terms of weight (which it seems to be at the moment) I
> don't think "technical debt" is an applicable term.
>

Technical debt isn't a measure of weight of transactions.  It's a measure
of the code complexity needed to implement, in this case, a Bitcoin Script
interpreter.

By itself, adding a single new hash format for CTV isn't that complex, and
it is certainly simpler than this TXHASH proposal.  But then we need to add
another two slightly different hash formats for APO support.  And tomorrow
we will need yet another set of transaction hash formats for the next
thing, and so on, with each instance requiring going through its own
soft-fork process.  It is at that point we end up with something more
complicated and with more deployment risk than if we had just done
something like TXHASH at the very beginning.  But unlike other programming
environments, we cannot refactor our way out of such a situation.  We
cannot make a new script version while deprecating the old one.  Our only
option here is to be mindful of the long term implications of the design
choices we are making today.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

On Thu, Jan 27, 2022 at 8:34 PM Anthony Towns  wrote:

> > An Alternative Proposal::
> >  ...
>
> > For similar reasons, TXHASH is not amenable to extending the set of
> txflags
> > at a later date.
>
> > I believe the difficulties with upgrading TXHASH can be mitigated by
> > designing a robust set of TXHASH flags from the start.  For example
> having
> > bits to control whether [...]
>
> I don't think that's really feasible -- eg, what you propose don't cover
> SIGHASH_GROUP:
>
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
>

For more complex interactions, I was imagining combining this TXHASH
proposal with CAT and/or rolling SHA256 opcodes.  If TXHASH ended up
supporting relative or absolute input/output indexes then users could
assemble the hashes of the particular inputs and outputs they care about
into a single signed message.


> > That all said, even if other txhash flag modes are needed in the future,
> > adding TXHASH2 always remains an option.
>
> I think baking this in from day 0 might be better: make TXHASH be
> a multibyte opcode, so that when you decode "0xBB" on the stack,
> you also decode a serialize.h:VarInt as the version number.


I wouldn't be opposed to this.

> ' CHECKSIGVERIFY can be simulated by '
> TXHASH  CHECKSIGFROMSTACKVERIFY'.
>
> I don't think that's quite right. BIP 118 anyprevout is done by taking
> the pubkey "P", marking it as "APO-capable" (by prefixing it with 0x01),
> and then getting a sighash and sig from the witness. Doing the same
> with TXHASH/CSFSV would just be replacing " CHECKSIGVERIFY" with
> "TXHASH  CSFSV" with the witness providing both the signature and
> txhash flag, just as separate elements rather than concatenated. (The
> "APO-capable" part is implicit in the "TXHASH" opcode)
>

Indeed. The TXHASH variant does require splitting the signature and txhash
flag across two stack items.  So it wouldn't be an operationally identical
drop in replacement.


> > In addition to the CTV and ANYPREVOUT applications, with
> > CHECKSIGFROMSTACKVERIFY we can verify signatures on arbitrary messages
> > signed by oracles for oracle applications.  This is where we see the
> > benefit of decomposing operations into primitive pieces.  By giving users
> > the ability to program their own use cases from components, we get more
> > applications out of fewer op codes!
>
> While I see the appeal of this from a language design perspective;
> I'm not sure it's really the goal we want. When I look at bitcoin's
> existing script, I see a lot of basic opcodes to do simple arithmetic and
> manipulate the stack in various ways, but the opcodes that are actually
> useful are more "do everything at once" things like check(multi)sig or
> sha256. It seems like what's most useful on the blockchain is a higher
> level language, rather than more of blockchain assembly language made
> up of small generic pieces. I guess "program their own use cases from
> components" seems to be coming pretty close to "write your own crypto
> algorithms" here...
>

Which operations in Script are actually composable today?

CHECKSIG composes with nothing else (other than possibly other CHECKSIGs)
as there are no other operations that manipulate pubkey keys or signature
data.

CLTV and CSV in principle can be composed with addition and subtraction and
comparison operations.  But where are you going to get other values to add
and subtract from?  I suppose you could compare the relative and absolute
locktimes to each other.

What do the HASH functions compose with?  Without CAT you cannot construct
messages to hash.  You can hash the result of the arithmetic operations,
but you are limited to hashing 32-bit (or 33-bit if you are generous)
strings, which is too little entropy to have any security properties.  You
can hash a public key or a signature I suppose.

I don't think there is much in the way of lessons to be drawn from how we
see Bitcoin Script used today with regards to programs built out of
reusable components.  User's haven't been composing programs, not because
they don't find composition useful, but rather because the existing
primitives do not lend themselves to being composed at all.

There is one aspect of Bitcoin Script that is composable, which is
(monotone) boolean combinations of the few primitive transaction conditions
that do exist.  The miniscript language captures nearly the entirety of
what is composable in Bitcoin Script today: which amounts to conjunctions,
disjunctions (and thresholds) of signatures, locktimes, and revealing hash
preimages.

TXHASH + CSFSV won't be enough by itself to allow for very interesting
programs Bitcoin Script yet, we still need CAT and friends for that, but
CSFSV is at least a step in that direction.  CSFSV can take arbitrary
messages and these messages can be fixed strings, or they can be hashes of
strings (that need to be revealed), or they can be hashes returned from
TXHASH, or they can be locktime values, or they can 

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

; properly (which might be tricky to do). Overall for the fields explicitly
> mentioned, seems safe, the "possibles" seem to have some more complex
> interactions. E.g., CTV with the ability to pick a subset of outputs would
> be exposed to quadratic hashing.
> 6) Missing field: covering the annex or some sub-range of the annex
> (quadratic hashing issues on the latter)
> 7) It seems simpler to, for many of these fields, push values directly (as
> in OP_PUSHTXDATA from Johnson Lau) because the combo of flags to push the
> hash of a single output's amount to emulate OP_AMOUNT looks 'general but
> annoying'. It may make more sense to do the OP_PUSHTXDATA style opcode
> instead. This also makes it simpler to think about the combinations of
> flags, since it's really N independent multi-byte opcodes.
>
>
> Ultimately if we had OP_TXHASH available "tomorrow", I would be able to
> build out the use cases I care about for CTV (and more). So I don't have an
> opposition on it with regards to lack of function.
>
> However, if one finds the TXHASH approach acceptable, then you should also
> be relatively fine doing APO, CTV, CSFS, TXHASH acceptable in any order
> (whenever "ready"), unless you are particularly sensitive to "technical
> debt" and "soft fork processes". The only costs of doing something for CTV
> or APO given an eventual TXHASH is perhaps a wasted key version or the 32
> byte argument of a NOP opcode and some code to maintain.
>
> Are there other costs I am missing?
>
> However, as it pertains to actual rollout:
>
> - OP_TXHASH+CSFSV doesn't seem to be the "full" set of things needed (we
> still need e.g. OP_CAT, Upgraded >=64 bit Math, TLUV or OP_TWEAK
> OP_TAPBRANCH OP_MANIPULATETAPTREE, and more) to full realize covenanting
> power it intends to introduce.
> - What sort of timeline would it take to ready something like TXHASH (and
> desired friends) given greater scope of testing and analysis (standalone +
> compared to CTV)?
> - Is there opposition from the community to this degree of
> general/recursive covenants?
> - Does it make "more sense" to invest the research and development effort
> that would go into proving TXHASH safe, for example, into Simplicity
> instead?
>
> Overall, *my opinion *is that:
>
> - TXHASH is an acceptable theoretical approach, and I am happy to put more
> thought into it and maybe draft a prototype of it.
> - I prefer CTV as a first step for pragmatic engineering and availability
> timeline reasons.
> - If TXHASH were to take, optimistically, 2 years to develop and review,
> and then 1 year to activate, the "path dependence of software" would put
> Bitcoin in a much better place were we to have CTV within 1 year and
> applications (that are to be a subset of TXHASH later) being built over the
> next few years enhanced in the future by TXHASH's availability.
> - There is an element of expediency meritted for something like CTV
> insofar as it provides primitives to tackle time sensitive issues around
> privacy, scalability, self custody, and decentralization. The
> aforementioned properties may be difficult to reclaim once given away (with
> the exception of perhaps scalability).
> - Bringing CTV to an implemented state of near-unanimous "we could do
> this, technically" is good for concretely driving the process of review for
> any covenant proposals forward, irrespective of if we ultimately activate.
> (I.e., if there were a reason we could not do CTV safely, it would likely
> have implications for any other future covenant)
>
> Concretely, I'm not going to stop advocating for CTV based on the above,
> but I'm very happy to have something new in the mix to consider!
>
> Best,
>
> Jeremy
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Wed, Jan 26, 2022 at 9:23 AM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Recapping the relationship between CTV and ANYPREVOUT::
>>
>> It is known that there is a significant amount of overlap in the
>> applications that are enabled by the CTV and ANYPREVOUT proposals despite
>> the fact that their primary applications (congestion control for CTV and
>> eltoo lightning channels for ANYPREVOUT) are quite distinct.
>> In particular, ANYPREVOUT can enable most of the applications of CTV,
>> albeit with a higher cost.  The primary functionality of CTV is to allow a
>> scriptPubKey to make a commitment to its spending transaction's hash with
>> the input's TXID excluded from the hash.  This exclusion is necessary
>> because the scriptPubKey 

[bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

Recapping the relationship between CTV and ANYPREVOUT::

It is known that there is a significant amount of overlap in the
applications that are enabled by the CTV and ANYPREVOUT proposals despite
the fact that their primary applications (congestion control for CTV and
eltoo lightning channels for ANYPREVOUT) are quite distinct.
In particular, ANYPREVOUT can enable most of the applications of CTV,
albeit with a higher cost.  The primary functionality of CTV is to allow a
scriptPubKey to make a commitment to its spending transaction's hash with
the input's TXID excluded from the hash.  This exclusion is necessary
because the scriptPubKey is hashed into the input's TXID, and including the
TXID would cause a cycle of hash commitments, which is impossible to
construct.  On the other hand, ANYPREVOUT defines a signature hash mode
that similarly excludes the inputs TXID for its purpose of rebindable
signatures.

This means that ANYPREVOUT can mimic most of the properties of CTV by
committing both a public key along with an ANYPREVOUT signature inside
scriptPubKey.  In fact, the only reason Bitcoin doesn't have covenants
today is due to this cycle between scriptPubKeys and the TXIDs that occur
in all the sighash modes.

The major differences between simulating CTV via ANYPREVOUT and the actual
CTV proposal is: (1) The cost of simulating CTV.  With CTV the spending
transaction is committed using a hash of 32 bytes, while simulating it with
ANYPREVOUT requires 64 bytes for a signature, and 32 bytes for some public
key, plus a few more bytes for various flags.  Some of that cost could be
reduced by using the inner public key (1 byte representation) and, if we
had CAT, maybe by assembling the signature from reusable pieces (i.e.
setting the nonce of the commited signature equal to the public key).

The other major difference is: (2) CTV's transaction hash covers values
such as the number of inputs in the transaction and their sequence numbers,
which ANYPREVOUT does not cover.  CTV's hash contains enough information so
that when combined with the missing TXIDs, you can compute the TXID of the
spending transaction.  In particular if the number of inputs is committed
to being 1, once the scriptpubkey's transaction id is known and committed
to the blockchain, the TXID of its spending transaction is deducible.  And
if that transaction has outputs that have CTV commitments in them, you can
deduce their spending TXIDs in turn.  While this is a pretty neat feature,
something that ANYPREVOUT cannot mimic, the main application for it is
listed as using congestion control to fund lightning channels, fixing their
TXIDs in advance of them being placed on chain.  However, if ANYPREVOUT
were used to mimic CTV, then likely it would be eltoo channels that would
be funded, and it isn't necessary to know the TXIDs of eltoo channels in
advance in order to use them.



An Alternative Proposal::

Given the overlap in functionality between CTV and ANYPREVOUT, I think it
makes sense to decompose their operations into their constituent pieces and
reassemble their behaviour programmatically.  To this end, I'd like to
instead propose OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY.

OP_TXHASH would pop a txhash flag from the stack and compute a (tagged)
txhash in accordance with that flag, and push the resulting hash onto the
stack.
OP_CHECKSIGFROMSTACKVERIFY would pop a pubkey, message, and signature from
the stack and fail if the signature does not verify on that message.

CTV and TXHASH have roughly equivalent functionality.  'CTV DROP' can be
simulated by ' TXHASH EQUALVERIFY'.  The reverse is also
true where ' TXHASH' can be simulated by CTV by
' CTV', however, as you can see, simulating
TXHASH from CTV is much more expensive than the other way around, because
the resulting 32-byte hash result must be included as part of the witness
stack.

' CHECKSIGVERIFY can be simulated by '
TXHASH  CHECKSIGFROMSTACKVERIFY'.  Here we see the advantage of
pushing the hash value onto the stack.  APO can be simulated without
needing to include a copy of the resulting txhash inside the witness data.

In addition to the CTV and ANYPREVOUT applications, with
CHECKSIGFROMSTACKVERIFY we can verify signatures on arbitrary messages
signed by oracles for oracle applications.  This is where we see the
benefit of decomposing operations into primitive pieces.  By giving users
the ability to program their own use cases from components, we get more
applications out of fewer op codes!



Caveats::

First, I acknowledge that replicating the behaviour of CTV and ANYPREVOUT
does cost a few more bytes than using the custom purpose built proposals
themselves.  That is the price to be paid when we choose the ability to
program solutions from pieces.  But we get to reap the advantages of being
able to build more applications from these pieces.

Unlike CTV, TXHASH is not NOP-compatable and can only be implemented within
tapscript.  In particular, bare CTV isn't possible with this 

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

[Russell O'Connor via bitcoin-dev]

On Wed, Jul 7, 2021 at 9:12 AM Russell O'Connor 
wrote:

>
> On Wed, Jul 7, 2021 at 12:26 AM ZmnSCPxj  wrote:
>
>> 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.
>>
>
> Unfortunately, when it comes to cross-transaction computations, it is
> infeasible to ban non-terminating computation.
>
> The nature of recursive covenants is that the program "writes" the *source
> code* next step of the computation to the scriptPubKey to one of the
> outputs of its transaction. Technically speaking it verifies that the
> scriptPubKey is a commitment to the source code of the next step of the
> program, but morally that is the same as writing the source code.  Then the
> next step of the computation is invoked by someone "evaluating* that next
> step's source code by creating a valid transaction that spends the
> generated output.
>
> The point is this ability to create new source code and then evaluate it
> leads to the ability to write universal (i.e non-terminating)
> computations.  The only way to prevent it is to ban source code
> manipulation, but since Bitcoin Script source code is just a string of
> bytes, it would mean banning the manipulation of strings of bytes.  But the
> entire Bitcoin Script language works by manipulating strings of bytes
> within a stack machine.  Indeed the most trivial of non-terminating
> programs can be implemented by extracting the current input's scriptPubKey
> from the sighash and "writing" the identical scriptPubKey to one of its
> outputs.  That example hardly takes any manipulation at all to implement.
>

A follow up:  Because recursive covenants need to be sent to a new
transaction in order to recurse, you might choose to view this stepping
mechanism as productive by modeling each transaction step as the continue
constructor in your RecResult codata type.  Indeed after (drinking coffee
and) rereading your mailing list item, it seems that this is the point you
were making.

So sorry for my hasty response.  I believe we are largely in agreement here.
___
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]

On Wed, Jul 7, 2021 at 12:26 AM ZmnSCPxj  wrote:

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

Unfortunately, when it comes to cross-transaction computations, it is
infeasible to ban non-terminating computation.

The nature of recursive covenants is that the program "writes" the *source
code* next step of the computation to the scriptPubKey to one of the
outputs of its transaction. Technically speaking it verifies that the
scriptPubKey is a commitment to the source code of the next step of the
program, but morally that is the same as writing the source code.  Then the
next step of the computation is invoked by someone "evaluating* that next
step's source code by creating a valid transaction that spends the
generated output.

The point is this ability to create new source code and then evaluate it
leads to the ability to write universal (i.e non-terminating)
computations.  The only way to prevent it is to ban source code
manipulation, but since Bitcoin Script source code is just a string of
bytes, it would mean banning the manipulation of strings of bytes.  But the
entire Bitcoin Script language works by manipulating strings of bytes
within a stack machine.  Indeed the most trivial of non-terminating
programs can be implemented by extracting the current input's scriptPubKey
from the sighash and "writing" the identical scriptPubKey to one of its
outputs.  That example hardly takes any manipulation at all to implement.
___
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] 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] 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 

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

[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 

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

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

[Russell O'Connor via bitcoin-dev]

There is one line written at
https://github.com/ElementsProject/elements/pull/949/files#r660130155. I
suppose we need to decide on which variants of *VERIFY and *ADD we want to
include (presumably all of them) and choose which opcodes they will be
assigned to.  And I guess for CHECKSIGFROMSTACKADD will want to place the n
value between the signature and the message on the stack.  ... So I suppose
we will need more than one sentence.

The semantics would be basically to call secp256k1_schnorrsig_verify <
https://github.com/bitcoin-core/secp256k1/blob/0440945fb5ce69d335fed32827b5166e84b02e05/include/secp256k1_schnorrsig.h#L158>,
treating pubkeys and signatures the same way the other CHECKSIG operations
do, and in passing the (variable length) message from the stack.
CHECKSIGFROMSTACK would also be subject to the same sigops budget that
CHECKSIG has in tapscript.

On Sat, Jul 3, 2021 at 2:30 PM Jeremy  wrote:

> Awesome to hear that!
>
> Actually I don't think I did know (or I forgot/didn't catch it) that there
> was an updated spec for elements, I searched around for what I could find
> and came up empty handed. Do you have any links for that? That sounds
> perfect to me.
>
>
> On Sat, Jul 3, 2021, 10:50 AM Russell O'Connor 
> wrote:
>
>> Hi Jermy,
>>
>> As you are aware, we, and by we I mean mostly Sanket, are developing an
>> updated OP_CHECKSIGFROMSTACK implementation for tapscript on elements.  The
>> plan here would be to effectively support the an interface to the
>> variable-length extension of BIP-0340 schnorr signatures.
>>
>> BIP-0340 would dispense with DER encoding (good riddance).
>> BIP-0340 signatures are batch verifiable along with other BIP-0340
>> transaction signatures and taproot tweak verification.
>> Support for variable length messages in BIP-0340 has been discussed in <
>> https://github.com/sipa/bips/issues/207> and an implementation has
>> recently been merged in <
>> https://github.com/bitcoin-core/secp256k1/pull/844>.  The BIP has not
>> yet been updated but the difference is that the message m does not have to
>> be 32-bytes (it is recommended that the message be a 32-bit tagged hash or
>> a message with a 64-bit application specific prefix). The CHECKSIGFROMSTACK
>> operation (in tapscript) would use a stack item for this m value to
>> BIP-0340 signature verification and would not necessarily have to be 32
>> bytes.
>>
>> I think this design we are aiming for would be perfectly suited for
>> Bitcoin as well.
>>
>> On Sat, Jul 3, 2021 at 12:32 PM Jeremy via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Reproduced below is the BIP text from Bitcoin Cash's (MIT-Licensed)
>>> specification for "CheckDataSig", more or less the same thing as
>>> CHECKSIGFROMSTACK
>>> https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdatasig.md.
>>> In contrast to Element's implementation, it does not have Element's bugs
>>> around verify semantics and uses the nullfail rule, and there is a
>>> specification document so it seemed like the easiest starting point for
>>> discussion v.s. drafting something from scratch.
>>>
>>> Does anyone have any issue with adapting this exact text and
>>> implementation to a BIP for Bitcoin using 2 OP_SUCCESSX opcodes?
>>>
>>> Note that with *just* CheckSigFromStack, while you can do some very
>>> valuable use cases, but without OP_CAT it does not enable sophisticated
>>> covenants (and as per
>>> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html
>>> just CAT alone enables such uses).
>>>
>>> Design questions worth considering as modifications:
>>>
>>> 1. Should CSFS require some sort of tagged hash? Very likely answer is
>>> no – tags interfere with certain use cases
>>> 2. Should CSFS split the signature’s R & S value stack items for some
>>> applications that otherwise may require OP_CAT? E.g. using a pinned R value
>>> allows you to extract a private key if ever double signed, using 2 R values
>>> allows pay-to-reveal-key contracts. Most likely answer is no, if that is
>>> desired then OP_CAT can be introduced
>>> 3. Should CSFS support a cheap way to reference the taproot internal or
>>> external key? Perhaps, can be handled with undefined upgradeable keytypes.
>>> One might want to use the internal key, if the signed data should be valid
>>> independent of the tapscript tree. One might want to use the external key,
>>> if the data should only be valid for a single tapscript key + tree.
>>> 4. Should invalid public keys types be a NOP to support future extended
>>> pubkey types?
>>>
>>>
>>>
>>> Best,
>>>
>>>
>>> Jeremy
>>>
>>>
>>> ---
>>> layout: specification
>>> title: OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY Specification
>>> category: spec
>>> date: 2018-08-20
>>> activation: 154230
>>> version: 0.6
>>> ---
>>>
>>> OP_CHECKDATASIG
>>> ===
>>>
>>> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY check whether a signature is 
>>> valid with respect to a message and a public key.
>>>

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

[Russell O'Connor via bitcoin-dev]

Hi Jermy,

As you are aware, we, and by we I mean mostly Sanket, are developing an
updated OP_CHECKSIGFROMSTACK implementation for tapscript on elements.  The
plan here would be to effectively support the an interface to the
variable-length extension of BIP-0340 schnorr signatures.

BIP-0340 would dispense with DER encoding (good riddance).
BIP-0340 signatures are batch verifiable along with other BIP-0340
transaction signatures and taproot tweak verification.
Support for variable length messages in BIP-0340 has been discussed in <
https://github.com/sipa/bips/issues/207> and an implementation has recently
been merged in .  The
BIP has not yet been updated but the difference is that the message m does
not have to be 32-bytes (it is recommended that the message be a 32-bit
tagged hash or a message with a 64-bit application specific prefix). The
CHECKSIGFROMSTACK operation (in tapscript) would use a stack item for this
m value to BIP-0340 signature verification and would not necessarily have
to be 32 bytes.

I think this design we are aiming for would be perfectly suited for Bitcoin
as well.

On Sat, Jul 3, 2021 at 12:32 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Reproduced below is the BIP text from Bitcoin Cash's (MIT-Licensed)
> specification for "CheckDataSig", more or less the same thing as
> CHECKSIGFROMSTACK
> https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdatasig.md.
> In contrast to Element's implementation, it does not have Element's bugs
> around verify semantics and uses the nullfail rule, and there is a
> specification document so it seemed like the easiest starting point for
> discussion v.s. drafting something from scratch.
>
> Does anyone have any issue with adapting this exact text and
> implementation to a BIP for Bitcoin using 2 OP_SUCCESSX opcodes?
>
> Note that with *just* CheckSigFromStack, while you can do some very
> valuable use cases, but without OP_CAT it does not enable sophisticated
> covenants (and as per
> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html just
> CAT alone enables such uses).
>
> Design questions worth considering as modifications:
>
> 1. Should CSFS require some sort of tagged hash? Very likely answer is no
> – tags interfere with certain use cases
> 2. Should CSFS split the signature’s R & S value stack items for some
> applications that otherwise may require OP_CAT? E.g. using a pinned R value
> allows you to extract a private key if ever double signed, using 2 R values
> allows pay-to-reveal-key contracts. Most likely answer is no, if that is
> desired then OP_CAT can be introduced
> 3. Should CSFS support a cheap way to reference the taproot internal or
> external key? Perhaps, can be handled with undefined upgradeable keytypes.
> One might want to use the internal key, if the signed data should be valid
> independent of the tapscript tree. One might want to use the external key,
> if the data should only be valid for a single tapscript key + tree.
> 4. Should invalid public keys types be a NOP to support future extended
> pubkey types?
>
>
>
> Best,
>
>
> Jeremy
>
>
> ---
> layout: specification
> title: OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY Specification
> category: spec
> date: 2018-08-20
> activation: 154230
> version: 0.6
> ---
>
> OP_CHECKDATASIG
> ===
>
> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY check whether a signature is valid 
> with respect to a message and a public key.
>
> OP_CHECKDATASIG permits data to be imported into a script, and have its 
> validity checked against some signing authority such as an "Oracle".
>
> OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY are designed to be implemented 
> similarly to OP_CHECKSIG [1]. Conceptually, one could imagine OP_CHECKSIG 
> functionality being replaced by OP_CHECKDATASIG, along with a separate Op 
> Code to create a hash from the transaction based on the SigHash algorithm.
>
> OP_CHECKDATASIG Specification
> -
>
> ### Semantics
>
> OP_CHECKDATASIG fails immediately if the stack is not well formed. To be well 
> formed, the stack must contain at least three elements [``, ``, 
> ``] in this order where `` is the top element and
>   * `` must be a validly encoded public key
>   * `` can be any string
>   * `` must follow the strict DER encoding as described in [2] and the 
> S-value of `` must be at most the curve order divided by 2 as described 
> in [3]
>
> If the stack is well formed, then OP_CHECKDATASIG pops the top three elements 
> [``, ``, ``] from the stack and pushes true onto the stack 
> if `` is valid with respect to the raw single-SHA256 hash of `` and 
> `` using the secp256k1 elliptic curve. Otherwise, it pops three 
> elements and pushes false onto the stack in the case that `` is the 
> empty string and fails in all other cases.
>
> Nullfail is enforced the same as for OP_CHECKSIG [3]. If the signature 

Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

[Russell O'Connor via bitcoin-dev]

On Sat, Jun 12, 2021 at 3:59 AM Billy Tetrud  wrote:

> >  taproot annex
>
> From what I can tell, the annex is basically additional inputs to a script
> that might have additional constraints put on it. Is that right? I don't
> quite follow how moving the max height to the annex helps script caching
> here. I wasn't able to find much information on how the annex is envisioned
> to be used. Would you mind elaborating on how this would work?
>
> Also, I think the proposal as it stands already addresses script caching
> (in the Transaction Evaluation section
> ).
> The result of the script can be cached as long as the cache item also
> contains information requiring just the OP_BBV to be re-evaluated (for the
> relevant block).
>

The normal approach for this problem would be a design that adds an "annex
field" (where the details on how to delimit annex fields is not yet
standardized) for a maxheight value, and add a consensus rule that
transaction with one (or more?) maxheight fields are invalid in blocks
whose height exceeds this (or any) maxheight value.  Then you could/would
add an OP code to push a copy of the (smallest) maxheight value from the
annex onto the stack or maybe an opcode to compare a stack item with this
(every) maxheight value from the annex.  This indirection is how OP_CLTV
and OP_CSV work and this indirection makes script validity cacheable
because script remains a function of the transaction data only.  Since
transaction data doesn't change, neither does the outcome of script
evaluation. The rule that invalidates late transactions looks only at the
annex and is independent of any script evaluation considerations.


> > this auto-double-spend wallet would send every payment with an annex value
> that limits the payment to being valid only up to the next block
>
> One possible solution to that would be to require that the input to OP_BBV
> to be in the script itself and not originate from the witness.
>
> Regardless, I think the ideal solution is to not have any of these such
> rules if we can simply change the definition for what counts as
> finalization to account for the fact that BBV transactions mined close to
> their expiration. Is there a reason this finalization-redefinition is not
> an adequate solution?
>

Generally speaking, you cannot solve security problems through optional and
completely voluntary transaction relay policy.  I'll just send my
about-to-expire transactions directly to miners and they will probably mine
them because they are, in fact, valid, and pay fees.  Why wouldn't they
mine it?

(Yes, I know this logic also applies to RBF flagged transactions.  Indeed,
you cannot rely on an RBF flag to prevent double spending,  Yes I think the
RBF flag ought to be removed from consideration and every transaction
should be considered RBFable.  Maybe that even happens to be my own node's
relay policy.)

I apologize, but I don't think I have further time to engage in an idea
that I don't consider likely to achieve broad community support.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

[Russell O'Connor via bitcoin-dev]

On Fri, Jun 11, 2021 at 7:12 AM James MacWhyte  wrote:

> @Billy I like the idea. It is very obvious how useful an opcode like this
> would be! (My background is in wallet implementation)
>
> @Russell I do understand your concerns of monotonism, however I'm having a
> hard time really coming up with an attack vector. You said "one can design
> a wallet to passively take advantage of reorgs by always spending through
> an OP_BBV that is on the verge of becoming invalid." Unless I'm mistaken,
> this means you would need to send yourself a fresh transaction using OP_BBV
> set to, say, 2 blocks in the future, then immediately spend that output in
> a new payment to someone else and hope a reorg happens. Does this mean the
> theoretical double-spend wallet you are proposing would have to send two
> transactions every time you make a single payment, doubling the transaction
> fees and adding more uncertainty around when the second transaction would
> get confirmed?
>

Assuming the proposal is rewritten to place the maxheight into the taproot
annex in order to address the issue with caching of script validity, then
this auto-double-spend wallet would send every payment with an annex value
that limits the payment to being valid only up to the next block.  If the
payment doesn't make it into the next block, then resign it with the annex
incremented to the next block, and repeat.


> In a normal double spend scenario, there is no cost to a failed attempt,
> but much to gain from a success. With your design, there is a real cost to
> every single attempt (transaction fees) and no evidence that the rate of
> success would be higher (you still have to bet on the reorg not including
> your transaction in the first few blocks). It sounds like this new system
> would actually be less attractive to double spenders than the current model!
>
> I also agree with Billy's idea for relay rules. We already have abusable
> chain rules (e.g. a tx can be included in a block with 0 transaction fee
> [spam?]) but we add protection with relay rules (e.g. minimum fee to
> relay). I don't see how this would be any different, if the chain rules
> only enforced the block height for confirmation and the relay rules forced
> a minimum OP_BBV value in order to protect against reorg double spends.
>

The inclusion of a tx with 0 transaction fee in a block is not in of itself
an abuse.  There is nothing wrong with blocks containing such
transactions.  The *relay* of 0 transaction fee transactions is what is an
abuse because it allows one to usurp Bitcoin's gossip network for their own
arbitrary communications platform without cost.  Most Bitcoin users aren't
signing up for being a usenet provider.  So, by policy, nodes require a
cost to relay transactions so that broadcasting isn't free. Even when that
price is paid to someone else, it still is an effective limitation on abuse.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

[Russell O'Connor via bitcoin-dev]

As it stands today, in order to double spend a transaction during a reorg,
one must take an active role of recognizing that a reorg has happened, hope
that the new branch has completely omitted your spending transaction, and
then quickly broadcast a replacement transaction with a higher fee to
outbid your previous transaction.

However with, pretty much any change to Bitcoin that leads to non-monotonic
validity rules, that is any rule where transactions that are valid at one
tip, can become invalid at a latter tip through some other means than their
inputs being spent, such as OP_BBV, one can design a wallet to passively
take advantage of reorgs by always spending through an OP_BBV that is on
the verge of becoming invalid.  Then you just have to sit back and wait for
a suitable reorg to take back your UTXO for you without any work.  I would
probably attempt to build such a wallet for myself should any OP_BBV-like
proposal be implemented.  Think of it as an auto-double spend wallet.

Some people hold the opinion that there is no meaningful distinction
between the active and passive roles in these two scenarios.  I'm not
convinced.  I see a material difference between needing to actively
broadcast a replacement transaction and passively waiting for your
transaction to fall out of validity.  I also see a material difference
between needing the transaction to be completely omitted from the reorging
chain versus just having the transaction fail a height qualification in the
reorging chain.

(There are a few other lesser problems with an OP_BBV proposal, including
the fact that Bitcoin software tends to cache script validity so you'd want
to use the taproot annex instead of pure script; and a possible issue that
the proposal defeats limits on transaction replacement because now instead
of meeting minimum thresholds for fee bumping you can just let the previous
transaction expire and bump the fee by a fraction (though you are
effectively rate limited so maybe that is considered sufficiently
mitigated?).  But there is little point in addressing these lesser concerns
if the main concern is outstanding.)

On Thu, Jun 10, 2021 at 6:20 PM Billy Tetrud  wrote:

> @Russell In that thread, you quoted Satoshi there, but neither he nor you
> really deeply explained the concern. Would you mind elaborating on a
> situation that calls for concern here? Some deeper explanation of the
> "reorg safety" property would also be helpful. I'd very much like to know
> what your thoughts are on the specific points I brought up in the BIP as
> well.
>
> On Thu, Jun 10, 2021 at 11:35 AM Russell O'Connor <
> rocon...@blockstream.com> wrote:
>
>> This is a continuation of the thread at
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018760.html
>> on this topic.
>>
>> I still remain unconvinced that we ought to give up on the "reorg safety"
>> property that is explicitly part of Bitcoin's design.
>>
>> On Thu, Jun 10, 2021 at 1:56 PM Billy Tetrud via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi Everyone,
>>>
>>> I'd like to open a discussion of an opcode I call OP_BEFOREBLOCKVERIFY
>>> (OP_BBV) which is similar to ones that have been discussed before (eg
>>> OP_BLOCKNUMBER). The opcode is very simple: the it takes as a parameter
>>> a number representing a block height, and marks the transaction invalid if
>>> the current block the transaction is being evaluated for is greater than or
>>> equal to that block height, the transaction is invalid. I wrote up a bip
>>> for OP_BBV here
>>> 
>>> .
>>>
>>> The motivation for this opcode is primarily to do switch-off kinds of
>>> transactions. Eg, an output that contains both a spend path that uses
>>> OP_BBV and a spend path that uses OP_CHECKSEQUENCEVERIFY so that before a
>>> particular block one person can spend, and after that block a different
>>> person can spend. This can allow doing things like expiring payments or
>>> reversible payments in a cheaper way. Currently, things like that require a
>>> sequence of multiple transactions, however OP_BBV can do it in a single
>>> transaction, making these applications a lot more economically feasible.
>>>
>>> The particular application I'm most interested in is more efficient
>>> wallet vaults. However, wallet vaults requires other new opcodes, and I've
>>> been given the (good, I think) advice to start off this discussion with
>>> something a bit more bite sized and manageable. So I want to keep this
>>> discussion to OP_BBV and steer away from the specifics of the wallet vaults
>>> I'm thinking of (which are more involved, requiring other new opcodes that
>>> I think makes more sense to discuss in a different thread).
>>>
>>> The main thing I'd like to discuss is the historical avoidance of and
>>> stigma toward opcodes that can cause a valid transaction to become invalid.
>>>
>>> It seems there 

Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

[Russell O'Connor via bitcoin-dev]

This is a continuation of the thread at
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018760.html
on this topic.

I still remain unconvinced that we ought to give up on the "reorg safety"
property that is explicitly part of Bitcoin's design.

On Thu, Jun 10, 2021 at 1:56 PM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Everyone,
>
> I'd like to open a discussion of an opcode I call OP_BEFOREBLOCKVERIFY
> (OP_BBV) which is similar to ones that have been discussed before (eg
> OP_BLOCKNUMBER). The opcode is very simple: the it takes as a parameter a
> number representing a block height, and marks the transaction invalid if
> the current block the transaction is being evaluated for is greater than or
> equal to that block height, the transaction is invalid. I wrote up a bip
> for OP_BBV here
> 
> .
>
> The motivation for this opcode is primarily to do switch-off kinds of
> transactions. Eg, an output that contains both a spend path that uses
> OP_BBV and a spend path that uses OP_CHECKSEQUENCEVERIFY so that before a
> particular block one person can spend, and after that block a different
> person can spend. This can allow doing things like expiring payments or
> reversible payments in a cheaper way. Currently, things like that require a
> sequence of multiple transactions, however OP_BBV can do it in a single
> transaction, making these applications a lot more economically feasible.
>
> The particular application I'm most interested in is more efficient wallet
> vaults. However, wallet vaults requires other new opcodes, and I've been
> given the (good, I think) advice to start off this discussion with
> something a bit more bite sized and manageable. So I want to keep this
> discussion to OP_BBV and steer away from the specifics of the wallet vaults
> I'm thinking of (which are more involved, requiring other new opcodes that
> I think makes more sense to discuss in a different thread).
>
> The main thing I'd like to discuss is the historical avoidance of and
> stigma toward opcodes that can cause a valid transaction to become invalid.
>
> It seems there are two concerns:
>
> 1. that an opcode like might create a DOS vector where a malicious actor
> might be able to spam the mempool with transactions containing this opcode.
> 2. that an opcode like this could cause "bad" reorg behavior, where in a
> reorg, transactions that were spent become not spend and not spendable
> because they were mined too near their expiry point.
>
> While I don't want to claim anything about opcodes that can cause spend
> paths to expire in general, I do want to claim that *some* opcodes like
> that are safe - in particular OP_BBV. In the context of OP_BBV
> specifically, it seems to me like item 1 (mempool handling) is a solvable
> problem and that point 2 (reorg issues) is not really a problem since
> people should generally be waiting for 6 confirmations and software can
> warn the user to wait for 6 confirmations in relevant scenarios where a
> 6-block reorg might reverse the transaction. I discuss this in detail in
> the Design Tradeoffs and Risks
> 
>  section
> of the document I wrote for OP_BBV. I'd love to hear thoughts from others
> on here about these things and especially the discussion of these issues in
> the document I linked to.
>
> Thanks,
> BT
>
> ___
> 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] BIP - limiting OP_RETURN / HF

[Russell O'Connor via bitcoin-dev]

Firstly, a minor point is that your proposal is a soft-fork, not a
hard-fork.

But more importantly, adding limitations on OP_RETURN transactions is not
helpful.  Users who want to embed arbitrary data in their transactions can
always do so by encoding their data inside the values of legacy
multi-signature scriptpubkeys (pubkeys can be generated without knowing the
private key in order to encode non-key related data).  Not only can users
do this, users have done this in the past.  However, this behaviour is
problematic because such multi-signature "data" scriptpubkeys are
indistinguishable from "real" multisignature scriptpubkeys, and thus must
be kept in the UTXO set.  This differs from outputs using OP_RETURN which
are provably unspendable, and therefore can be safely omitted from the UTXO
set.

Thus, given that it is otherwise impossible to stop people from putting
arbitrary data values into their transactions, then we rather encourage
people who are going to encode their arbitrary data in transaction to use
the OP_RETURN outputs in order to avoid UTXO bloat.

Also, as it stands, fees already nudge various participants to consolidate
their data in the way that you suggest they do.

On Fri, Apr 16, 2021 at 9:32 AM Christopher Gilliard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I have created a BIP which can be found here:
> https://github.com/cgilliard/bips/blob/notarization/bip-.mediawiki
>
> I'm sending this email to start the discussion regarding this proposal. If
> there are any comments/suggestions, please let me know.
>
> Regards,
> Chris
> ___
> 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] maximum block height on transaction

[Russell O'Connor via bitcoin-dev]

>From https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119:

We can't safely do OP_BLOCKNUMBER.  In the event of a block chain reorg
> after a segmentation, transactions need to be able to get into the chain in
> a later block.  The OP_BLOCKNUMBER transaction and all its dependants would
> become invalid.  This wouldn't be fair to later owners of the coins who
> weren't involved in the time limited transaction.
>
> nTimeLock does the reverse.  It's an open transaction that can be replaced
> with new versions until the deadline.  It can't be recorded until it
> locks.  The highest version when the deadline hits gets recorded.  It could
> be used, for example, to write an escrow transaction that will
> automatically permanently lock and go through unless it is revoked before
> the deadline.  The feature isn't enabled or used yet, but the support is
> there so it could be implemented later.
>

Unfortunately, limiting the maximum block height for a specific transaction
would have exactly the same problem as cited above for OP_BLOCKNUMBER.

On Fri, Apr 9, 2021 at 7:21 AM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> is there any way to specify a maximum block height on a transaction?
>
> ie: this tx is only valid if included in a block with a certain height or
> less
>
> i feel like this would be useful
> ___
> 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] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

[Russell O'Connor via bitcoin-dev]

On Tue, Apr 6, 2021 at 12:27 PM Russell O'Connor 
wrote:

> On Tue, Apr 6, 2021 at 12:23 PM David A. Harding  wrote:
>
>>
>>   You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days" )
>>
>> Ten minute estimators can say:
>>
>>   You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 * 2016))
>> minutes" )
>>
>> And nine minute estimators can say:
>>
>>   You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((9 * 2016))
>> minutes" )
>>
>
> It isn't  "$MIN_LOCKIN_TIME + $((10 * 2016)) minutes". It's
> "$MIN_LOCKIN_TIME + time until next retargeting period + $((10 * 2016))
> minutes".
>

Not only that, but the "time_until_next_retargeting_period" is a variable
whose distribution could straddle between 0 days and 14 days should the
MIN_LOCKIN_TIME end up close to a retargeting boundary.  MTP risks having a
persistent two week error in estimating the activation time (which is the
time that nodes need to strive to be upgraded) which may not be resolved
until only two weeks prior to activation!  If MIN_LOCKIN_TIME ends up close
to a retargeting boundary, then the MTP estimate becomes bimodal and
provides much worse estimates than provided by height based activation,
just as we are approaching the important 4 weeks (or is it 2 weeks?) prior
to activation!

Compare this with height based activation which simply becomes more and
more accurate in its estimation consistently (until, at less than two weeks
prior to activation, the height based estimate and the corresponding MTP
estimate have identical distributions because they both become height based
at that point in time.) This works out nicely because of the overall
simpler and easier to reason about design of height based activation.

The short of it is that MTP LOCKIN only really guarantees a minimum 2 week
notice prior to activation, which is largely the purpose of that LOCKIN
period.  Whereas height based activation gives an estimate whose
distribution smoothly and continuously becomes more and more accurate as
activation approaches, with no abrupt changes in estimates.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

[Russell O'Connor via bitcoin-dev]

On Tue, Apr 6, 2021 at 12:23 PM David A. Harding  wrote:

>
>   You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days" )
>
> Ten minute estimators can say:
>
>   You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 * 2016))
> minutes" )
>
> And nine minute estimators can say:
>
>   You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((9 * 2016))
> minutes" )
>

It isn't  "$MIN_LOCKIN_TIME + $((10 * 2016)) minutes". It's
"$MIN_LOCKIN_TIME + time until next retargeting period + $((10 * 2016))
minutes".
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

[Russell O'Connor via bitcoin-dev]

I'm pretty sure that the question of "is signalling still possible by the
time enough miners have upgraded and are ready to start signalling?"
Strongly benefits from a guaranteed number of signaling periods that height
based activation offers.  Especially for the short activation period of
Speedy Trial.

The other relevant value of giving enough time for users to upgrade is not
very sensitive.  It's not like 180 days is magic number that going over is
safe and going below is unsafe.

That said, as Jeremy has pointed out before (maybe it was on IRC), we can
almost ensure a minimum of 7 retargeting periods by carefully selecting
signaling start and end dates to line up in the middle of expected
retargeting periods that we would otherwise chose with height based
activation. Why we would rather use MTP to fake a height based activation,
I will never understand. But if this is what it takes to activate taproot,
that is fine by me.

The differences between height and MTP activation are too small to matter
that much for what is ultimately transient code.  As long as MTP activation
can pass code review it is okay with me.


On Mon., Apr. 5, 2021, 06:35 Anthony Towns via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Apr 03, 2021 at 09:39:11PM -0700, Jeremy via bitcoin-dev wrote:
> > As such, the main conversation in this agenda item is
> > around the pros/cons of height or MTP and determining if we can reach
> consensus
> > on either approach.
>
> Here's some numbers.
>
> Given a desired signalling period of xxx days, where signaling begins
> on the first retarget boundary after the starttime and ends on the last
> retarget boundary before the endtime, this is how many retarget periods
> you get (based on blocks since 2015-01-01):
>
>  90 days: mainnet  5-7 full 2016-block retarget periods
> 180 days: mainnet 11-14
> 365 days: mainnet 25-27
> 730 days: mainnet 51-55
>
> (This applies to non-signalling periods like the activation/lock in delay
> too of course. If you change it so that it ends at the first retarget
> period after endtime, all the values just get incremented -- ie, 6-8,
> 12-15 etc)
>
> If I've got the maths right, then requiring 1814 of 2016 blocks to signal,
> means that having 7 periods instead of 5 lets you get a 50% chance of
> successful activation by maintaining 89.04% of hashpower over the entire
> period instead of 89.17%, while 55 periods instead of 51 gives you a 50%
> chance of success with 88.38% hashpower instead of 88.40% hashpower.
> So the "repeated trials" part doesn't look like it has any significant
> effect on mainnet.
>
> If you target yy periods instead of xxx days, starting and ending on a
> retarget boundary, you get the following stats from the last few years
> of mainnet (again starting at 2015-01-01):
>
>  1 period:  mainnet 11-17 days (range 5.2 days)
>  7 periods: mainnet 87-103 days (range 15.4 days)
> 13 periods: mainnet 166-185 days (range 17.9 days)
> 27 periods: mainnet 352-377 days (range 24.4 days)
> 54 periods: mainnet 711-747 days (range 35.0 days)
>
> As far as I can see the questions that matter are:
>
>  * is signalling still possible by the time enough miners have upgraded
>and are ready to start signalling?
>
>  * have nodes upgraded to enforce the new rules by the time activation
>occurs, if it occurs?
>
> But both those benefit from less real time variance, rather than less
> variance in the numbers of signalling periods, at least in every way
> that I can think of.
>
> Corresponding numbers for testnet:
>
>  90 days: testnet   5-85
> 180 days: testnet  23-131
> 365 days: testnet  70-224
> 730 days: testnet 176-390
>
> (A 50% chance of activating within 5 periods requires sustaining 89.18%
> hashpower; within 85 periods, 88.26% hashpower; far smaller differences
> with all the other ranges -- of course, presumably the only way the
> higher block rates ever actually happen is by someone pointing an ASIC at
> testnet, and thus controlling 100% of blocks for multiple periods anyway)
>
>   1 period:  testnet 5.6minutes-26 days (range 26.5 days)
>  13 periods: testnet 1-135 days (range 133.5 days)
>  27 periods: testnet 13-192 days (range 178.3 days)
>  54 periods: testnet 39-283 days (range 243.1 days)
> 100 periods: testnet 114-476 days (range 360.9 days)
>  (this is the value used in [0] in order to ensure 3 months'
>   worth of signalling is available)
> 132 periods: testnet 184-583 days (range 398.1 days)
> 225 periods: testnet 365-877 days (range 510.7 days)
> 390 periods: testnet 725-1403 days (range 677.1 days)
>
> [0] https://github.com/bitcoin/bips/pull/1081#pullrequestreview-621934640
>
> Cheers,
> aj
>
> ___
> 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

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Russell O'Connor via bitcoin-dev]

Hi Andrew,

This is a slight misunderstanding of the proposal.  Rather than an extended
lockin period (a term I've erroneously used in the past) it is really a
minimum activation height.

Thus using your figures it would instead be:

* start height = 681408 /* about May 1st */
* timeout height = 695520 /* about Aug 7th */
* min activation height = 709632 /* about Nov 13th */
* lockinontimeout = False
* signaling bit = 2
* threshold = 1815/2016 blocks (90%)

This guarantees 7 retargeting periods between start height and timeout
height.

Being able to make a guarantee about how many retargeting periods we get is
perhaps something worth pursuing given that the signaling period is so
short for this trial.

On Sat, Mar 6, 2021 at 1:04 AM Andrew Chow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I like this idea.
>
> In terms of actual parameters, I propose that we base this Speedy Trial
> off of BIP 8 with the following parameters:
> * start height = 681408
> * timeout height = 695520
> * lockinontimeout = False
> * signaling bit = 2
> * threshold = 1815/2016 blocks (90%)
>
> For the extended lockin period, I propose 14112 blocks, which is 7
> retarget periods. Thus the earliest activation height will be 697536 and
> the latest activation height will be 709632.
>
> This will give us an approximate start time of May 1st 2021 and an
> approximate timeout time of August 7th 2021, for a total activation
> period of just over 3 months. The extended lockin period is the same
> number of blocks as the activation period so that will also be just over
> 3 months, giving us the latest activation time of November 13th, 2021.
> If miners activated as soon as possible, the earliest activation time
> would be August 21st 2021.
>
> Additionally, this timeline assumes a mid-April release of Bitcoin Core
> 0.21.1 containing these parameters. They could be changed to move up if
> the expected release date were sooner.
>
>
> Andrew Chow
>
> On 3/5/21 10:43 PM, David A. Harding via bitcoin-dev wrote:
> > On the ##taproot-activation IRC channel, Russell O'Connor recently
> > proposed a modification of the "Let's see what happens" activation
> > proposal.[1] The idea received significant discussion and seemed
> > acceptable to several people who could not previously agree on a
> > proposal (although this doesn't necessarily make it their first
> > choice).  The following is my attempt at a description.
> >
> > 1. Start soon: shortly after the release of software containing this
> > proposed activation logic, nodes will begin counting blocks towards
> > the 90% threshold required to lock in taproot.[2]
> >
> > 2. Stop soon: if the lockin threshold isn't reached within approximately
> > three months, the activation attempt fails.  There is no mandatory
> > activation and everyone is encouraged to try again using different
> > activation parameters.
> >
> > 2. Delayed activation: in the happy occasion where the lockin threshold
> > is reached, taproot is guaranteed to eventually activate---but not
> > until approximately six months after signal tracking started.
> >
> > ## Example timeline
> >
> > (All dates approximate; see the section below about BIP9 vs BIP8.)
> >
> > - T+0: release of one or more full nodes with activation code
> > - T+14: signal tracking begins
> > - T+28: earliest possible lock in
> > - T+104: locked in by this date or need to try a different activation
> process
> > - T+194: activation (if lockin occurred)
> >
> > ## Analysis
> >
> > The goal of Speedy Trial is to allow a taproot activation attempt to
> > either quickly succeed or quickly fail---without compromising safety in
> > either case.  Details below:
> >
> > ### Mitigating the problems of early success
> >
> > New rules added in a soft fork need to be enforced by a large part of
> > the economy or there's a risk that a long chain of blocks breaking the
> > rules will be accepted by some users and rejected by others, causing a
> > chain split that can result in large direct losses to transaction
> > receivers and potentially even larger indirect losses to holders due to
> > reduced confidence in the safety of the Bitcoin system.
> >
> > One step developers have taken in the past to ensure widespread adoption
> > of new consensus rules is programming in a delay between the time
> software
> > with those rules is expected to be released and when the software starts
> > tracking which blocks signal for activation.  For example:
> >
> >  Soft fork| Release| Start  | Delta
> >  -+++--
> >  BIP68 (v0.12.1)  | 2016-04-15 | 2016-05-11 | 26 days
> >  BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days
> >
> >  Sources: BitcoinCore.org,
> https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
> >
> > Speedy Trial replaces most of that upfront delay with a backend delay.
> > No matter how fast taproot's activation threshold 

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Russell O'Connor via bitcoin-dev]

Appologies as I've rearranged your comments in my reply.

On Wed, Mar 3, 2021 at 5:14 PM Matt Corallo 
wrote:

>
> On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote:
>
> After a normal and successful Core update with LOT=false, we will have
> more data showing broad community support for the
> > taproot upgrade in hand.
>
> I think this is one of the strongest arguments against a flag day
> activation, but, as I described in more detail in the
> thread "Straight Flag Day (Height) Taproot Activation", I'm not sure we
> aren't there enough already.
>

I agree with you.  I also think we have plenty of evidence to proceed with
taproot and could proceed with a PR for such a flag day activation.  If
there is support for it to be merged, that would be fantastic.  I think we
should proceed along these lines forthwith.

However, the existence and/or release of a flag day activation code does
not in of itself preclude concurrently developing and/or releasing a BIP8
LOT=false deployment.  Activating taproot is "idempotent" after all. We
could even do a Core release with a flag day activation while we continue
to discuss BIP8 LOT=false if that gets the ball rolling.  Certainly having
a flag day activation code merged would take a lot of pressure off further
BIP8 LOT=false work.

As Aaron noted on IRC, if the sticking point here is the MUST_SIGNAL state,
then running BIP8 LOT=false alongside a flag day activation at timeout may
be the way to go.  Once a flag day deployment is released, the LOT=true
people would have their guaranteed activation and would be less interested
in an alternative client. And without a MUST_SIGNAL state, I believe the
LOT=false deployment won't lead any hashpower that is following
standardness rules to create invalid blocks.


> > In the next release, 6 months later or so, Core could then confidently
> deploy a BIP8 LOT=true
>
> Could you clarify what an acceptable timeline is, then? Six months from
> release of new consensus rules to activation (in
> the case of a one-year original window) seems incredibly agressive for a
> flag-day activation, let alone one with
> forced-signaling, which would require significantly higher level of
> adoption to avoid network split risk. In such a
> world, we'd probably get Taproot faster with a flag day from day one.
>

Whatever timeline people are in favour of.  I think having a year or more
between the LOT=true or flag day more and the anticipated second release
date is fair myself.
That would suggest a 2-year timeout from the start to give plenty of room.

Of course, if we start with a flag day from the start then we can just do 1
year and we don't need a second deployment.

We could also do a "Let’s see what happens" with a short 3 or 4-month
deployment and still do a follow up activation if that is more agreeable.
That would give a net of about 1.5 years or so because we don't need to
anticipate the second relase date.

I'm good with whatever, and I'm happy to make more concrete suggestions if
that is necessary.  I think there exist acceptable timelines here.


> > client, should it prove to be necessary.  A second Core deployment of
> LOT=true would mitigate some of the concerns with
> > LOT=false, but still provide a period beforehand to objective actions
> taken by the community in support of taproot.  We
> > don't even have to have agreement today on a second deployment of
> LOT=true after 6 months to start the process of a
> > LOT=false deployment. The later deployment will almost certainly be
> moot, and we will have 6 months to spend debating
> > the LOT=true deployment versus doing a flag day activation or something
> else.
>


> That was precisely the original goal with the LOT=false movement - do
> something easy and avoid having to hash out all
> the technical details of a second deployment. Sadly, that's no longer
> tennable as a number of people are publicly
> committed to deploying LOT=true software on the network ASAP.
>



First things last:

> Even today, I still think that starting with BIP8 LOT=false is, generally
> speaking, considered a reasonably safe
> > activation method in the sense that I think it will be widely considered
> as a "not wholly unacceptable" approach to
> > activation.
>
> How do you propose avoiding divergent consensus rules on the network,
> something which a number of commentors on this
> list have publicly committed to?
>

Firstly, it is an open network.  Anyone can join and run whatever consensus
rules they want.  People have run divergent consensus rules on the network
in the past and it will continue to do so in the future.
It is troublesome when it happens in mass, but it isn't fatal.  We can't
prevent it, and we should continue working to keep the protocol robust in
the face of it.
And

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Russell O'Connor via bitcoin-dev]

While I support essentially any proposed taproot activation method,
including a flag day activation, I think it is premature to call BIP8 dead.

Even today, I still think that starting with BIP8 LOT=false is, generally
speaking, considered a reasonably safe activation method in the sense that
I think it will be widely considered as a "not wholly unacceptable"
approach to activation.

After a normal and successful Core update with LOT=false, we will have more
data showing broad community support for the taproot upgrade in hand.  In
the next release, 6 months later or so, Core could then confidently deploy
a BIP8 LOT=true client, should it prove to be necessary.  A second Core
deployment of LOT=true would mitigate some of the concerns with LOT=false,
but still provide a period beforehand to objective actions taken by the
community in support of taproot.  We don't even have to have agreement
today on a second deployment of LOT=true after 6 months to start the
process of a LOT=false deployment. The later deployment will almost
certainly be moot, and we will have 6 months to spend debating the LOT=true
deployment versus doing a flag day activation or something else.

I don't think we need to start self-sabotaging our efforts to get taproot
activated this year just yet.  Let's cherry-pick the commits of PR #19573
to split it up into non-MUST_SIGNAL and MUST_SIGNAL components, and get
some reviews on that first.  Then afterwards we can decide if BIP8 is dead
or not.

On Wed, Mar 3, 2021 at 9:39 AM Chris Belcher via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The bitcoin world is close to total gridlock on the question of how to
> activate taproot. There's no agreement on activation[1][2], and if an
> agreement isn't reached then nothing happens. That would be really
> terrible because we'd miss out on the benefits of taproot and
> potentially other future soft forks.
>
> A major problem with BIP8 is that it would result to a situation where
> different parts of the bitcoin ecosystem run different consensus rules.
> Some people will run LOT=true and others LOT=false. Worst of all, it
> becomes vulnerable to a twitter/reddit/social media blitz which could
> attempt to move the date of miner activation around.
>
> Twitter and reddit drama provide a perfect cover for social attacks on
> bitcoin.
>
> Forced signalling leads to brinksmanship. Where two or more sides
> (backed up by social media drama) enter into a game of chicken with
> deployed nodes. If one of them doesn't concede then we get a damaging
> chain split. And the $1 trillion in value that the bitcoin network
> protects is put at risk. From the point of view of a miner or big
> exchange stuck in the middle, if they look at the ecosystem of twitter
> and reddit (especially if you think about all the problems with bots and
> sockpuppets) they have no idea which consensus rules they should
> actually follow and exactly what date they take effect. Miners,
> exchanges, merchants and the rest of the ecosystem exist to serve their
> customers and users, and trouble happens when they don't know what their
> customers really want. Social media attacks are not just a theoretical
> concern; back during the block size drama, the bitcoin reddits were
> targetted by bots, sockpuppets and brigading[3].
>
> Enter flag day activation. With a flag day there can be no
> brinksmanship. A social media blitz cant do anything except have its own
> followers fork away. Crucially, miner signalling cant be used to change
> the activation date for nodes that didn't choose to and just passively
> follow signalling. Changing the activation date requires all those users
> to actually run different node software.
>
> Flag day activation works simply: we choose a block height and after
> that block height the new taproot rules become enforced.
>
>
> Supporters of the permissionless, "users rule" approach of LOT=true
> should be happy because it completely takes miners out of activation.
>
> Supporters of the safe, conservative approach of LOT=false can be made
> happy with a few ways of derisking:
>
> * Getting mining pools, businesses and users to look at the code and ask
> if they (a) think its either neutral or good for their business or use
> case and (b) they believe others view it similarly and that the
> consensus changes proposed have a good social consensus around them.
>
> * Setting the flag day far in the future (18 months or 2 years in the
> original proposal[3]).
>
>
> == What if flag day activation is used maliciously? ==
>
> What if one day the Core developer team is co-opted and uses the flag
> day method to do something bad? For example, a soft fork where sending
> to certain blacklisted addresses is not allowed. The bitcoin user
> community who wants to resist this can create their own
> counter-soft-fork full node, where the first block after the flag day
> MUST pay to one of those addresses on the blacklist. This forces a chain
> split between the 

Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)

[Russell O'Connor via bitcoin-dev]

On Thu, Oct 8, 2020 at 11:00 AM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Rather than go through that again, I'd prefer we use the
> backwards compatible proposal from BIPs PR#945 and, if we want to
> maximize safety, consensus restrict v1 witness program size, e.g. reject
> transactions with scriptPubKeys paying v1 witness programs that aren't
> exactly 32 bytes.
>

Adding some kind of relay policy rule would be easier than a consensus
rule, and maybe effective enough.  (This comment is not intended to endorse
any one proposal over another.)


> Hopefully by the time we want to use segwit v2, most software will have
> implemented length limits and so we won't need any additional consensus
> restrictions from then on forward.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] On the compatibility of Bech32 and Shamir's Secret Sharing

[Russell O'Connor via bitcoin-dev]

With the help of Pieter I've recently made some interesting mathematical
observations about Bech32 codewords and Shamir's secret sharing:

(1) Affine combinations of two Bech32 codewords is again a valid Bech32
codeword.
(2) Lagrange polynomials form a partition of unity.

The consequences of these facts is that when you perform Shamir's secret
sharing where all your shares have valid Bech32 checksums, then the
resulting secret will also have a valid Bech32 checksum.  Conversely, if
your secret has a valid Bech32 checksum, and your random shares have valid
Bech32 checksums, then all your derived shares will have valid Bech32
checksums.  This can form a basis on which we can build a simple secret
sharing scheme for dividing up a BIP-32 master seed.

In order to illustrate this, I'll describe an example scheme for *k*-of-*n*
Shamir's secret sharing scheme where *2 <= k* <= *n* <= 31.

Suppose we have a 128-bit master seed 0xb6721d937d82f238672de4db91b87d0c.
We encode this secret as the following Bech32 codeword: "
donotusesss321s2name00keepmymasterseedunderwraps2n89wr".  Let's deconstruct
this codeword.

"donotusesss32": A Bech32 hrp for this example scheme.
"1": The Bech32 separator.
"s": The first data character is the index of this share. Each index is a
Bech32 character.  In this scheme the secret share is always at index "s",
which stands for "secret".
"2": The second data character is the threshold.  In this example we are
using a 2-of-n threshold.  We use the digits 2-9 for thresholds upto 9.  We
use Bech32 characters a-y for thresholds from 10 to 31.
"name00": The next 6 characters are an id for this set of shares.  This id
isn't part of the secret data. It is used to ensure that the shares you are
reconstructing were generated for the same secret.  This id just needs to
be unique for all the secrets that you are dividing up with this scheme.
The id can be chosen randomly, sequentially, or even set to the constant
such as "qq" if you do not want to use it for identification.
"keepmymasterseedunderwraps": This is the 128-bit secret master seed
0xb6721d937d82f238672de4db91b87d0c encoded in Bech32.  The master seed can
be a 128-bit, 256-bit or 512-bit value.
"2n89wr" is the Bech32 checksum.

We will generate shares for a 2-of-3 threshold.  We generate the first
share at index "a".  In this example we generate "
donotusesss321a2name00q0h5aajczn04g9sh0wtsl2f0y0g3vlkr".

"donotusesss32": The Bech32 hrp for this example scheme.
"1": The Bech32 separator.
"a": The first data character is the index of this share which we have
chosen to be "a".
"2": The second data character is the threshold, which is 2.
"name00": The next 6 characters is the id we chose above for this set of
shares.
"q0h5aajczn04g9sh0wtsl2f0y0": This is 26 randomly selected bech32 characters
"g3vlkr" is the Bech32 checksum.

We generated the next two shares at index "c" and and index "d".  These
shares are generated using characterwise Lagrange interpolation of the
secret share and the above randomly generated share.
The resulting shares are "
donotusesss321c2name00chzu58ep57hd9xmaw6zmuyjeau0kq4mr" and "
donotusesss321d2name00ung8rmkf2snftj57zu45g7z84hzmzk4r"

Notice that the resulting strings have
(1) valid checksums;
(2) have correct indices;
(3) have the correct threshold values;
(4) have the correct ids.

This scheme still enjoys the perfect information hiding property of
Shamir's secret sharing.  Even when you know *k*-1 shares, every possible
master seed value has exactly one set of shares that includes those
particular *k*-1 shares, so knowing *k*-1 shares tells you nothing about
the secret data value.

One nice property of Lagrange interpolation is that it is simple enough to
compute by hand with the help of a few lookup tables.  Bech32 checksums can
also be computed and checked by hand with the help of lookup tables.  While
the majority of users wouldn't do hand computations, those motivated users
who have a healthy distrust of digital devices can generate and manipulate
the secret shares by hand.  The Bech32 checksum property means that after
generating the shares by hand, you can then validate the checksums by hand.
With extremely high probability, you will catch any computation error you
make.  My SSS32 repository at https://github.com/roconnor-blockstream/SSS32
has a postscript file that generates the lookup tables needed for hand
computation, although the document is a bit disorganized at the moment.

The main deficiency of the scheme presented here is that we want a longer
checksum than used in BIP-173 that is more suitable for error correction,
rather than simply error detection.

This example scheme was inspired in part by SLIP-32
 with the
intent to be a hand computable version of the same idea.

P.S. It is possible that this all could be made obsolete by a threshold
musig signature scheme.
___
bitcoin-dev mailing 

Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses

[Russell O'Connor via bitcoin-dev]

The bold values are the witness program lengths and address lengths of the
segwit v0 programs (BIP-141), which clearly need to be covered in my
proposed amendment.  32 bytes is also the proposed witness program length
for segwit v1 that would correspond to a taproot (BIP-341) program.

On Wed, Jul 15, 2020 at 5:05 PM Greg Sanders  wrote:

> Can you make it clear what the bold vs not-bold numbers mean?
>
> On Wed, Jul 15, 2020 at 4:56 PM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>>
>>> That brings me to Matt's point: there is no need to do this right now.
>>> We can simply amend BIP173 to only permit length 20 and length 32 (and only
>>> length 20 for v0, if you like; but they're so far apart that permitting
>>> both shouldn't hurt), for now. Introducing the "new" address format (the
>>> one using an improved checksum algorithm) only needs to be there in time
>>> for when a non-32-byte-witness-program would come in sight.
>>>
>>
>> As a prerequisite to taproot activation, I was looking into amending
>> BIP173 as stated above.  However after reviewing
>> https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb#detection-of-insertion-errors
>> it seems that insertions of 5 characters or more is "safe" in the sense
>> that there is low probability of creating a valid checksum by doing so
>> randomly.
>>
>> This means we could safely allow witness programs of lengths *20*, 23,
>> 26, 29, *32*, 36, and 40 (or 39).  These correspond to Bech32 addresses
>> of length *42*, 47, 52, 57, *62*, 68, and 74 (or 73).  We could also
>> support a set of shorter addresses, but given the lack of entropy in such
>> short addresses, it is hard to believe that such witness programs could be
>> used to secure anything.  I'm not sure what the motivation for allowing
>> such short witness programs was, but I'm somewhat inclined to exclude them
>> from the segwit address format.
>>
>> Given that we would only be able to support one of 39 or 40 byte witness
>> programs, it is sensible to choose to allow 40 byte witness programs to be
>> addressable.  This is the maximum witness program size allowed by BIP 141.
>>
>> So my proposal would be to amend BIP173 in such a way to restrict "bc"
>> and "tb" segwit address formats to require witness programs be of size
>> *20*, 23, 26, 29, *32*, 36, or 40.  Witness programs of other sizes
>> (between 2 and 40) would, of course, still be legal in accordance with BIP
>> 141; however they would be unaddressable by using this "bc" and "tb"
>> prefix.  Another address format would be needed to support other witness
>> sizes, should the need ever arise.
>>
>> --
>> Russell O'Connor
>> ___
>> 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] Bech32 weakness and impact on bip-taproot addresses

[Russell O'Connor via bitcoin-dev]

On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> That brings me to Matt's point: there is no need to do this right now. We
> can simply amend BIP173 to only permit length 20 and length 32 (and only
> length 20 for v0, if you like; but they're so far apart that permitting
> both shouldn't hurt), for now. Introducing the "new" address format (the
> one using an improved checksum algorithm) only needs to be there in time
> for when a non-32-byte-witness-program would come in sight.
>

As a prerequisite to taproot activation, I was looking into amending BIP173
as stated above.  However after reviewing
https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb#detection-of-insertion-errors
it seems that insertions of 5 characters or more is "safe" in the sense
that there is low probability of creating a valid checksum by doing so
randomly.

This means we could safely allow witness programs of lengths *20*, 23, 26,
29, *32*, 36, and 40 (or 39).  These correspond to Bech32 addresses of
length *42*, 47, 52, 57, *62*, 68, and 74 (or 73).  We could also support a
set of shorter addresses, but given the lack of entropy in such short
addresses, it is hard to believe that such witness programs could be used
to secure anything.  I'm not sure what the motivation for allowing such
short witness programs was, but I'm somewhat inclined to exclude them from
the segwit address format.

Given that we would only be able to support one of 39 or 40 byte witness
programs, it is sensible to choose to allow 40 byte witness programs to be
addressable.  This is the maximum witness program size allowed by BIP 141.

So my proposal would be to amend BIP173 in such a way to restrict "bc" and
"tb" segwit address formats to require witness programs be of size *20*,
23, 26, 29, *32*, 36, or 40.  Witness programs of other sizes (between 2
and 40) would, of course, still be legal in accordance with BIP 141;
however they would be unaddressable by using this "bc" and "tb" prefix.
Another address format would be needed to support other witness sizes,
should the need ever arise.

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

Re: [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN

[Russell O'Connor via bitcoin-dev]

I don't believe that 60 bytes is a problem here.  SHA256 padding includes a
length value of the original message data. Thus a padded non-64 byte
transaction can never be the same as any padded 64-byte value, and
therefore after applying the SHA256 compression function the resulting
hashes cannot be identical (unless SHA256 itself is broken).

P.S. SHA256 also includes 10* padding, which also suffices to ensure
messages of different lengths have different padding.

On Sat, May 23, 2020 at 8:52 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Thomas,
>
> > So I think the question to ask would be "why can't we just make sure
> it's not 64?"
>
> If we accept a 60-byte tx, then SHA-256 will pad it to 64 bytes, and it
> may still be possible to mount CVE-2017-12842 attack with 32-bits of work.
> Of course some other details will be changed from the standard SHA-256 in
> mounting this attack, but from my poor understanding it seems safer to just
> avoid the area around length 64.
>
> It *might* be safe to accept 65-byte or larger (but do not believe me, I
> only play a cryptographer on the Internet), but that does not help your
> specific application, which uses 60 byte tx.
>
> Regards,
> ZmnSCPxj
>
> >
> > On Sat, May 23, 2020 at 11:24 AM Greg Sanders 
> wrote:
> >
> > > AFAIU the number was picked to protect against CVE-2017-12842
> covertly. See: https://github.com/bitcoin/bitcoin/pull/16885 which
> updated the text to explicitly mention this fact.
> > >
> > > On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > >
> > > > Hello list,
> > > >
> > > > I have been trying to CPFP a transaction using OP_RETURN, because the
> > > > remaining output value would have been lower than the dust threshold.
> > > >
> > > > The scriptPubkey of the output was OP_RETURN + OP_0, and there was a
> > > > single p2wsh input.
> > > >
> > > > The result is a 60 bytes transaction (without witness), that gets
> > > > rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE,
> which
> > > > is equal to 82 bytes.
> > > >
> > > > Why is that value so high? Would it make sense to lower it to 60?
> > > >
> > > > Thomas
> > > > ___
> > > > 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] BIP-341: Committing to all scriptPubKeys in the signature message

[Russell O'Connor via bitcoin-dev]

On Sat, May 2, 2020 at 10:26 AM Anthony Towns  wrote:

>
> except that we'd arguably still be missing:
>
> is this a coinbase output? (Coin.fCoinBase)
> what was the height of the coin? (Coin.nHeight)
>
> Maybe committing to the coinbase flag would have some use, but committing
> to the height would make it hard to chain unconfirmed spends, so at
> least that part doesn't seem worth adding.
>

To add to this point, the height of the coin is something that is *not*
currently covered by any signature mode and including it would constitute a
change of an entirely different  caliber; a change that I would strongly
caution against for your above reason and more.

The coinbase output flag is currently covered by the signature as the
outpoint hash has the required information (its prevout index of 0x
is only legal in a coinbase transaction).  While I'm not particularly
enthusiastic about making it easier to distinguish coinbase outputs from
other outputs, and I worry a little about alternative designs for
implementing the Bitcoin protocol where this information is not so readily
available, I suppose I won't really oppose adding it.  However, I don't
think anyone is seriously proposing it.
-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message

[Russell O'Connor via bitcoin-dev]

> If you didn't verify the output scriptPubKeys, you would *only* be able
> to care about fees since you couldn't verify where any of the funds went?
> And you'd only be able to say fees are "at least x", since they could be
> more if one of the scriptPubKeys turned out to be OP_TRUE eg. That might
> almost make sense for a transaction accelerator that's trying to increase
> the fees; but only if you were doing it for someone else's transaction
> (since otherwise you'd care about the output addresses) and only if you
> were happy to not receive any change? Seems like a pretty weird use case?
>

You are right of course.  I was thinking of cases where you only care about
where some of the outputs go but not all.  But of course, even in that case
you will need to wade through all of the output ScriptPubKeys anyways.
The current design shares the hashOuputs value with the one computed with
BIP-143, and that is a somewhat valuable property to keep.

Thanks for setting me straight.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message

[Russell O'Connor via bitcoin-dev]

While I'm not entirely convinced yet that accertaining non-ownership of an
input is a robust method of solving the problem here, I also see little
reason not to amend BIP-341 as proposed. The ScriptPubKeys in question is
already indirectly covered through the outpoints, so it is just a matter of
optimization.  Furthermore in the consensus code, the ScriptPubKeys are
part of the UTXO data set, and it is already being retrieved as part of the
transaction checking process, so it is readily available.

I'm not sure how much my opinion on the topic matters, but I did include
this kind of functionality in my design for Simplicity on Elements, and I
have been leaning towards adding this kind of functionality in my Bitcoin
demo application of Simplicity.

Regarding specifics, I personally think it would be better to keep the
hashes of the ScriptPubKeys separate from the hashes of the input values.
This way anyone only interested in input values does not need to wade
through what are, in principle, arbitrarily long ScriptPubKeys in order to
check the input values (which each fixed size).  To that end, I would also
(and independently) propose separating the hashing of the output values
from the output ScriptPubKeys in `sha_outputs` so again, applications
interested only in summing the values of the outputs (for instance to
compute fees) do not have to wade through those arbitrarily long
ScriptPubKeys in the outputs.

On Thu, Apr 30, 2020 at 4:22 AM Andrew Kozlik via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi everyone,
>
> In the current draft of BIP-0341 [1] the signature message commits to the
> scriptPubKey of the output being spent by the input. I propose that the
> signature message should commit to the scriptPubKeys of *all* transaction
> inputs.
>
> In certain applications like CoinJoin, a wallet has to deal with
> transactions containing external inputs. To calculate the actual amount
> that the user is spending, the wallet needs to reliably determine for each
> input whether it belongs to the wallet or not. Without such a mechanism an
> adversary can fool the wallet into displaying incorrect information about
> the amount being spent, which can result in theft of user funds [2].
>
> In order to ascertain non-ownership of an input which is claimed to be
> external, the wallet needs the scriptPubKey of the previous output spent by
> this input. It must acquire the full transaction being spent and verify its
> hash against that which is given in the outpoint. This is an obstacle in
> the implementation of lightweight air-gapped wallets and hardware wallets
> in general. If the signature message would commit to the scriptPubKeys of
> all transaction inputs, then the wallet would only need to acquire the
> scriptPubKey of the output being spent without having to acquire and verify
> the hash of the entire previous transaction. If an attacker would provide
> an incorrect scriptPubKey, then that would cause the wallet to generate an
> invalid signature message.
>
> Note that committing only to the scriptPubKey of the output being spent is
> insufficient for this application, because the scriptPubKeys which are
> needed to ascertain non-ownership of external inputs are precisely the ones
> that would not be included in any of the signature messages produced by the
> wallet.
>
> The obvious way to implement this is to add another hash to the signature
> message:
> sha_scriptPubKeys (32): the SHA256 of the serialization of all
> scriptPubKeys of the previous outputs spent by this transaction.
>
> Cheers,
> Andrew Kozlik
>
> [1]
> https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.html
> ___
> 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] Overview of anti-covert-channel signing techniques

[Russell O'Connor via bitcoin-dev]

On Sun, Mar 22, 2020 at 5:43 AM Tim Ruffing  wrote:

> On Sat, 2020-03-21 at 12:59 -0400, Russell O'Connor wrote:
> > Public keys are deterministic and can be spot checked.  In fact,
> > AFAIU if hardened HD key derivations are not used, then spot checking
> > is very easy.
> >
> > While spot checking isn't ideal, my original concern with the
> > synthetic none standard proposal was that it is inherently non-
> > deterministic and cannot ever be spot checked.  This is why anti-
> > covert signing protocols are so important if we are going to use
> > synthetic nonces.
>
> If spot checking means checking a few instances, then I think this is a
> pretty weak defense. What if the device starts to behave differently
> after a year?
>

I agree, which is why there perhaps is merit in using a non-hardered
derivation path so that the software side of a hardware wallet can check
the pubkey. Though I understand there are some disadvantages to the
non-hardened paths.

However, spot checking can even be done retroactively (and thoroughly).
Again, I agree that this is less than ideal, but does let you take some
action once you notice a deviation.

Your claim is that if we don't fix the pubkey issue there is no point in
fixing the signature issue.  I disagree.  While I think both issues need to
be fully addressed, the issues around the original proposed
non-deterministic signature scheme are far more severe. The proposal would
move us from a deterministic scheme, where spot checks are possible, with
all the caveats that entails, to a non-deterministic scheme where spot
checks are impossible.  My hope is that we can standardise a scheme that
has the advantages of non-determinism without the threat of covert channels.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Overview of anti-covert-channel signing techniques

[Russell O'Connor via bitcoin-dev]

On Sat, Mar 21, 2020 at 12:46 PM Tim Ruffing via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Pieter,
>
> Let's take a step back first. If we believe that malicious hardware
> wallets are big enough of a concern, then signing is only part of the
> problem. The other issue is key generation. The PRG from which the seed
> is derived can be malicious, e.g., just H(k_OO,counter) for a key k_OO
> chosen by the hardware manufacturer. I haven't seen an argument why
> attacks during the signing model should more realistic than attacks
> during key generation, so I'd be very hesitant to deploy anti-covert
> channel singing protocols without deploying protocols for key
> generation that are secure in the same attacker model.
>

Public keys are deterministic and can be spot checked.  In fact, AFAIU if
hardened HD key derivations are not used, then spot checking is very easy.

While spot checking isn't ideal, my original concern with the synthetic
none standard proposal was that it is inherently non-deterministic and
cannot ever be spot checked.  This is why anti-covert signing protocols are
so important if we are going to use synthetic nonces.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Removing Single Point of Failure with Seed Phrase Storage

[Russell O'Connor via bitcoin-dev]

On Wed, Feb 26, 2020 at 2:56 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> As a replacement for paper, something like this makes sense v.s. what you
> do with a ledger presently.
>
> However, shamir's shares notoriously have the issue that the key does
> exist plaintext on a device at some point.
>
> Non-interactive multisig has the benefit of being able to sign
> transactions without having keys in the same room/place/device ever.
> --
> @JeremyRubin 
> 
>

The way I see it, the main benefit of Shamir's Secret Sharing is for those
people who are already willing or wanting to be able to sign transactions
on a single device, in a single room, etc., but would prefer not to keep
their secret backup in a single room/place/device.  It is one thing to go
and gather your shares whenever you need to recover from a broken/wiped
hardware wallet versus having to go gather your shares whenever you want to
make a transaction.  (I do agree that SSS is not a suitabl for creating a
multisig from multiple participants.)

This thread inspired me tidy up and post my concept for creating secret
shares using paper computers (slide charts) and can be found at
https://github.com/roconnor-blockstream/SSS32/blob/master/SSS32.ps. It is a
design for splitting a secret encoded in the Bech32 alphabet into 2-of-n
shares (where n <= 31) using pencil, paper and lookup tables.  There are
numerous issues  and
more that need to be addressed before one could even think about using it
for actual valuable data.  Right now I'm mostly interested to find out if
paper sharing is really feasible.

A secret of 26 random Bech32 characters provides 130 bits of entropy, and a
secret of 51 random Bech32 characters provides 255 bits of entropy.
However, to enable robust recovery, the secret data ought to contain an
error correcting code.  Because each character of the secret is
independently split into shares, any single character error in one of the
shares translates into a single character error in the recovered secret
which can be corrected by the error correcting code.  See the exercise at
the end of "Verifying Bech32 Checksums with Pen and Paper" <
http://r6.ca/blog/20180106T164028Z.html> on how to attach the Bech32 error
correcting code to a raw secret string by hand.  However, protecting the
secret data is so important that one would want to design a checksum BCH
code longer than 6 characters to get strong error correcting capabilities.

I still don't know if this proposed method all a good idea or not.  I've
only experimented with encoding and recovering a 10 character "secret"
data.  Generating 2-of-n shares is quite easy as all the shares are a
function of the secret share and the first random share.  It only takes
lookup up a pair of coordinates in a table to generate one character for
each of the n shares together.  Recovering the secret data is more work;
however, if your plan is to recover a hardware wallet anyways, it is
reasonable for the hardware wallet to do the recovery from the shares
itself for you.  Generating the error correcting code by hand is a bit more
worrying, because it doesn't do you much good if your generate an incorrect
checksum.  However, by doing 1 or 2 manual passes to verify the checksum is
maybe adequate.  Also passing the secret data into the hardware wallet you
wish to use, along with its checksum, would let the hardware wallet tell
you if there was an error in the checksum.  I think creating more general
3-of-n schemes can be implemented too, but require work similar to recovery
to generate rather than the simple lookup table process.  Generating 4-of-n
and higher schemes may also be possible, but would require even more hand
computation (i.e. computing lagrange polynomials.)

Maybe this scheme is workable for the subset of people that this would
appeal to.  In anycase, my document is open source and available for those
who want to tinker with it.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Fwd: BIP 340 updates: even pubkeys, more secure nonce generation

[Russell O'Connor via bitcoin-dev]

On Sun, Feb 23, 2020 at 11:26 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> 2. Nonce generation
>
> All other semantical changes are around more secure nonce generation
> in BIP 340, dealing with various failure cases:
>
> * To protect against fault injection attacks it is recommended to
> include actual signing-time randomness into the nonce generation
> process. This was mentioned already, but the update elaborates much
> more about this, and integrates this randomness into the standard
> signing process.
>

I do worry that standardizing on a non-deterministic nonce generation
scheme makes the problem of private key exfiltration a much bigger concern
in the application of hardware signing devices.
While sorely imperfect, with a deterministic nonce scheme, we at least have
the option of spot checking hardware devices to see if they are producing
signatures in accordance with their specified nonce scheme.  But short of
providing some kind of certificate, we won't be able to do such checks
against hardware devices that use the proposed synthetic nonce. (Question:
can a hardware device safely output the random value 'a' it used its
"certificate"?  AFAIU 'a' is not considered secret data; it just needs to
be not under attacker control.  Should hardware wallets be encouraged to
return this value?)

The best way to mitigate this is to use the Nonce exfiltration protection
mentioned; however there are no references on how to do this.  Ideally we'd
standardize this Nonce exfiltration protection scheme within this synthetic
nonce scheme.  However, I don't think it is worth holding this BIP up on
that; it seems reasonable to introduce a new section to this BIP addressing
that problem in the future.  Maybe instead we can get references to more
information about this Nonce exfiltration protection that is mentioned?

Really I just want to do whatever we reasonably can do to avoid a world
where we end up providing hardware signing devices with a hard to detect
underhanded communications channel.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Signing CHECKSIG position in Tapscript

[Russell O'Connor via bitcoin-dev]

After chatting with andytoshi and others, and some more thinking I've been
convinced that my specific concern about other users masquerading other
people pubkeys as their own in complex scripts is actually a non-issue.

No matter what you write in Script (today), you are limited to expressing
some policy that is logically equivalent to a set of conditions and
signatures on pubkeys that can be expressed in disjunctive normal form.  We
can write such a policy as

(C[1] && PK[1,1] && ... && PK[1,m[1]]) || ... || (C[n] && PK[n,1] && ... &&
PK[n,m[n]])

where C[i] is some conjunction of conditions such as timelock constraints,
or hash-lock constraints or any other kind of proof of publication, and
where PK[i,j] is a requirement of a signature against a specific public key.

>From Alice's point of view, she can divide set of clauses under the
disjunction into those that contain a pubkey that she considers (partially)
under her control and those clauses that she does not control (even though
as we shall see those other keys might actually be under Alice's control,
unbeknownst to her). To that end, let us consider a specific representative
policy.

(C[1] && APK[1]) || (C[2] && APK[2] && BPK[2]) || (C[3] && BPK[3])

where Alice considers herself in control of APK[1] and APK[2], and where
she considers Bob in control of BPK[2] and BPK[3] and where C[1], C[2], and
C[3] are different conditions, let's say three different hash-locks.  We
will also say that Alice has ensured that her pubkeys in different clauses
are different (i.e. APK[1] != APK[2]), but she doesn't make any such
assumption for Bob's keys and neither will we.

When Alice funded this Script, or otherwise accepted it for consideration,
she agreed that she wouldn't control the redemption of the UTXO as long as
the preimage for C[3] is published.  In particular, Alice doesn't even need
to fully decode the Script semantics for that clause beyond determining
that it enforces the C[3] requirement that she cares about. Even if Bob was
masquerading Alice's pubkey as his own (as in BPK[3] = APK[1] or BPK[3] =
APK[2]), and he ends up copying her signature into that clause, Alice ends
up with C[3] published as she originally accepted as a possibility.  Bob
masquerading Alice's pubkey as his own only serves to hamper his own
ability to sign for his clauses (I mean, Bob might be trying to convince
some third party that Alice signed for something she didn't actually sign
for, but such misrepresentations of the meaning of digital signatures is
outside our scope and this just serves as a reminder not to be deceived by
Bob's tricks here).

And the same argument holds for BPK[2].  Even if BPK[2] = APK[1] and Bob
tries to copy Alice's signature into the C[2] condition, he still needs a
countersignature with her APK[2], so Alice remains in control of that
clause.  And if BPK[2] = APK[2] then Bob can only copy Alice's signature on
the C[2] condition, but in that case she has already authorised that
condition.  Again, Bob masquerading Alice's pubkey as his own only serves
to hamper his own ability to sign for his clauses.

So what makes our potential issue here safe, versus the dangers that would
happen in  where Bob
masqurades Alice's UTXO as his own?  The key problem in the UTXO case isn't
so much Bob masquerading Alice's pubkey as his own, as it is an issue with
Alice reusing her pubkeys and Bob taking advantage of that.  We do, in
fact, have exactly the same issue in Script.  If Alice were to reuse
pubkeys such that APK[1] = APK[2], then Bob could take her signature for
C[1] and transplant it to redeem under condition C[2].  We see that it is
imperative that Alice ensures that she doesn't reuse pubkeys that she
considers under her control for different conditions when she wants her
signature to distinguish between them.

For various reasons, some historical, it is much harder to avoid pubkey
reuse for different UTXOs than it is to avoid pubkey reuse within a single
script.  We often use Bitcoin addresses in non-interactive ways, such as
putting them on flyers or painting them on walls and such.  Without a
standard for tweaking such pubkeys in a per-transaction way, we end up with
a lot of pubkey reuse between various UTXOs.  However, within a Script,
avoiding pubkey reuse ought to be easier.  Alice must communicate different
pubkeys intended for different clauses, or if Bob is constructing a whole
complex script on Alice's behalf, he may need to add CODESEPARATORs if
tweaking Alice's pubkey isn't an option.

The conversion of a policy to disjunctive normal form can involve an
exponential blowup (see <
https://en.wikipedia.org/wiki/Disjunctive_normal_form#Conversion_to_DNF>).
For instance, if Alice's policy (not in disjunctive normal form) is of the
form

(C[1] || D[1]) && ... && (C[n] || D[n]) && APK

where C[i] and D[i] are all distinct hashlocks, we require O(2^n) clauses
to put it in disjunctive normal form.  If 

Re: [bitcoin-dev] Signing CHECKSIG position in Tapscript

[Russell O'Connor via bitcoin-dev]

On Thu, Nov 28, 2019 at 3:07 AM Anthony Towns  wrote:

> FWIW, there's discussion of this at
> http://www.erisian.com.au/taproot-bip-review/log-2019-11-28.html#l-65
>

I think variants like signing the position of the enclosing
OP_IF/OP_NOTIF/OP_ELSE of the OP_IF/OP_NOTIF/OP_ELSE block that the
checksig is within, or signing the byte offset instead of the opcode number
offset are all fine.  In particular, signing the enclosing OP_IF... would
allow sharing of the hashed signed data in a normal multisig sequence of
operations.  Below I'll continue to refer to my proposal as signing the
CHECKSIG position, but please take it to mean any of these proposed,
semantically equivalent, realizations of this idea.

I also think that it is quite reasonable to have a sighash flag control
whether or not the signature covers the CHECKSIG position or not, with
SIGHASH_ALL including the CHECKSIG position.


> First, it seems like a bad idea for Alice to have put funds behind a
> script she doesn't understand in the first place. There's plenty of
> scripts that are analysable, so just not using ones that are too hard to
> analyse sure seems like an option.
>

I don't think this is true in general.  When constructing a script it seems
quite reasonable for one party to come to the table with their own custom
script that they want to use because they have some sort of 7-of-11 scheme
but in one of those cases is really a 2-of-3 and another is 5-of-6.  The
point is that you shouldn't need to decode their exact policy in order to
collaborate with them.  This notion is captured quite clearly in the MAST
aspect of taproot.  In many circumstances, it is sufficient for you to know
that there exists a branch that contains a particular script without need
to know what every branch contains.  Because we include the tapleaf in the
signature, we already prevent this signature copying attack against
attempts to transplant one's signature from one tapleaf to another.  My
proposal is to simply extend this same protection to branches within a
single tapscript.

Second, if there are many branches in the script, it's probably more
> efficient to do them via different branches in the merkle tree, which
> at least for this purpose would make them easier to analyse as well
> (since you can analyse them independently).
>

Of course this should be done when practical.  This point isn't under
dispute.


> Third, if you are doing something crazy complex where a particular key
> could appear in different CHECKSIG operators and they should have
> independent signatures, that seems like you're at the level of
> complexity where learning about CODESEPARATOR is a reasonable thing to
> do.
>

So while I agree that learning about CODESEPARATOR is a reasonable thing to
do, given that I haven't heard the CODESEPARATOR being proposed as
protection against this sort of signature-copying attack before and given
the subtle nature of the issue, I'm not sure people will know to use it to
protect themselves.  We should aim for a Script design that makes the
cheaper default Script programming choices the safer one.

On the other hand, in a previous thread a while ago I was also arguing that
sophisticated people are plausibly using CODESEPARATOR today, hidden away
in unredeemed P2SH UTXOs.  So perhaps I'm right about at least one of these
two points. :)

I think CODESEPARATOR is a better solution to this problem anyway. In
> particular, consider a "leaf path root OP_MERKLEPATHVERIFY" opcode,
> and a script that says "anyone in group A can spend if the preimage for
> X is revelaed, anyone in group B can spend unconditionally":
>
>  IF HASH160 x EQUALVERIFY groupa ELSE groupb ENDIF
>  MERKLEPATHVERIFY CHECKSIG
>
> spendable by
>
>  siga keya path preimagex 1
>
> or
>
>  sigb keyb path 0
>
> With your proposed semantics, if my pubkey is in both groups, my signature
> will sign for position 10, and still be valid on either path, even if
> the signature commits to the CHECKSIG position.
>
> I could fix my script either by having two CHECKSIG opcodes (one for
> each branch) and also duplicating the MERKLEPATHVERIFY; or I could
> add a CODESEPARATOR in either IF branch.
>

> (Or I could just not reuse the exact same pubkey across groups; or I could
> have two separate scripts: "HASH160 x EQUALVERIFY groupa MERKLEPATHVERIFY
> CHECKSIG" and "groupb MERKLEPATHVERIFY CHECKSIG")
>

I admit my proposal doesn't automatically prevent this signature-copying
attack against every Script template.  To be fully effective you need to be
aware of this signature-copying attack vector to ensure your scripts are
designed so that your CHECKSIG operations are protected by being within the
IF block that does the verification of the hash-preimage.  My thinking is
that my proposal is effective enough to save most people most of the time,
even if it doesn't save everyone all the time, all while having no
significant burden otherwise.  Therefore, I don't think your point that
there still exists a 

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

[Russell O'Connor via bitcoin-dev]

Thanks for this work Jeremy.

I know we've discussed this before, but I'll restate my concerns with
adding a new "global" state variable to the Script interpreter for tracking
whether the previous opcode was a push-data operation or not.  While it
isn't so hard to implement this in Bitcoin Core's Script interpreter,
adding a new global state variable adds that much more complexity to anyone
trying to formally model Script semantics.  Perhaps one can argue that
there is already (non-stack) state in Script, e.g. to deal with
CODESEPARATOR, so why not add more?  But I'd argue that we should avoid
making bad problems worse.

If we instead make the CHECKTEMPLATEVERIFY operation fail if it isn't
preceded by (or alternatively followed by) an appropriate sized
(canonical?) PUSHDATA constant, even in an unexecuted IF branch, then we
can model the Script semantics by considering the
PUSHDATA-CHECKTEMPLATEVERIFY pair as a single operation.  This allows
implementations to consider improper use of CHECKTEMPLATEVERIFY as a
parsing error (just as today unbalanced IF-ENDIF pairs can be modeled as a
parsing error, even though that isn't how it is implemented in Bitcoin
Core).

I admit we would lose your soft-fork upgrade path to reading values off the
stack; however, in my opinion, this is a reasonable tradeoff.  When we are
ready to add programmable covenants to Script, we'll do so by adding CAT
and operations to push transaction data right onto the stack, rather than
posting a preimage to this template hash.

Pleased to announce refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY
> (replaces previous OP_SECURETHEBAG BIP). Primarily:
>
> 1) Changed the name to something more fitting and acceptable to the
> community
> 2) Changed the opcode specification to use the argument off of the stack
> with a primitive constexpr/literal tracker rather than script lookahead
> 3) Permits future soft-fork updates to loosen or remove "constexpr"
> restrictions
> 4) More detailed comparison to alternatives in the BIP, and why
> OP_CHECKTEMPLATEVERIFY should be favored even if a future technique may
> make it semi-redundant.
>
> Please see:
> BIP: https://github.com/JeremyRubin/bips/blob/ctv/bip-ctv.mediawiki
> Reference Implementation:
> https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify
>
> I believe this addresses all outstanding feedback on the design of this
> opcode, unless there are any new concerns with these changes.
>
> I'm also planning to host a review workshop in Q1 2020, most likely in San
> Francisco. Please fill out the form here
> https://forms.gle/pkevHNj2pXH9MGee9 if you're interested in participating
> (even if you can't physically attend).
>
> And as a "but wait, there's more":
>
> 1) RPC functions are under preliminary development, to aid in testing and
> evaluation of OP_CHECKTEMPLATEVERIFY. The new command `sendmanycompacted`
> shows one way to use OP_CHECKTEMPLATEVERIFY. See:
> https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-rpcs.
> `sendmanycompacted` is still under early design. Standard practices for
> using OP_CHECKTEMPLATEVERIFY & wallet behaviors may be codified into a
> separate BIP. This work generalizes even if an alternative strategy is used
> to achieve the scalability techniques of OP_CHECKTEMPLATEVERIFY.
> 2) Also under development are improvements to the mempool which will, in
> conjunction with improvements like package relay, help make it safe to lift
> some of the mempool's restrictions on longchains specifically for
> OP_CHECKTEMPLATEVERIFY output trees. See: 
> https://github.com/bitcoin/bitcoin/pull/17268
> This work offers an improvement irrespective of OP_CHECKTEMPLATEVERIFY's
> fate.
>
>
> Neither of these are blockers for proceeding with the BIP, as they are
> ergonomics and usability improvements needed once/if the BIP is activated.
>
> See prior mailing list discussions here:
>
> *
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.html
> *
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/016997.html
>
> Thanks to the many developers who have provided feedback on iterations of
> this design.
>
> Best,
>
> Jeremy
>
> --
> @JeremyRubin 
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Signing CHECKSIG position in Tapscript

[Russell O'Connor via bitcoin-dev]

Hi all,

I'd like to revisit an old topic from last year about the data signed in
tapscript signatures <
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016508.html
>.

The current tapscript proposal requires a signature on the last executed
CODESEPRATOR position.  I'd like to propose an amendment whereby instead of
signing the last executed CODESEPRATOR position, we simply always sign the
position of the CHECKSIG (or other signing opcode) being executed. Then we
can deprecate CODESEPARTOR (either by making it OP_SUCCESS, or a nop, or
always fail when executed, or whatever).

The main motivation for this proposal is to increase robustness against
various signature-copying attacks in Scripts that have multiple spending
conditions.  Bitcoin is already robust against attacks where the attacker
attempts to peddle a victim's UTXO as their own and try to copy the
victim's signature from one transaction input to another input.  Because
Bitcoin signatures specify which input within a transaction is being signed
for, such attacks fail (see https://bitcoin.stackexchange.com/a/85665/49364
).

However, unless CODESEPARATOR is explicitly used, there is no protection
against these sorts of attacks when there are multiple participants that
have signing conditions within a single UTXO (or rather within a single
tapleaf in the tapscript case).  As it stands, Bitcoin's signed data only
covers which input is being signed, and not the specific conditions are
being signed for.  So for example, if Alice and Bob are engaged in some
kind of multi-party protocol, and Alice wants to pre-sign a transaction
redeeming a UTXO but subject to the condition that a certain hash-preimage
is revealed, she might verify the Script template shows that the code path
to her public key enforces that the hash pre-image is revealed (using a
toolkit like miniscript can aid in this), and she might make her signature
feeling secure that it, if her signature is used, the required preimage
must be revealed on the blockchain.  But perhaps Bob has masquated Alice's
pubkey as his own, and maybe he has inserted a copy of Alice's pubkey into
a different path of the Script template.  Now Alice's signature can be
copied and used in this alternate path, allowing the UTXO to be redeemed
under circumstances that Alice didn't believe she was authorizing.  In
general, to protect herself, Alice needs to inspect the Script to see if
her pubkey occurs in any other branch.  Given that her pubkey, in
principle, could be derived from a computation rather that pushed directly
into the stack, it is arguably infeasible for Alice to perform the required
check in general.

I believe that it would be safer, and less surprising to users, to always
sign the CHECKSIG position by default.  This will automatically enforce
conditions with the signature in most cases, rather than requiring users to
proactively try to reason if CODESEPARATOR is required for protection
within their protocol or not, and risk having them leave it out for cost
savings when it ends up being required for security after all.

I do not believe signing the CHECKSIG position is an undue burden on those
signers who have no conditions they require enforcement for.  As it stands,
the tapscript proposal already requires the tapleaf_hash value under the
signature; this CHECKSIG position value is simply more of the same kind of
data.  In simple Script templates (e.g. those with only one CHECKSIG
operation) the signed position will be a fixed known value.  Complex Script
templates are precisely the situations where you want to be careful about
enforcement of conditions with your signature.

As a side benefit, we get to eliminate CODESEPARATOR, removing a fairly
awkward opcode from this script version.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot proposal

[Russell O'Connor via bitcoin-dev]

Hmm? If I'm following what you mean, that's not the P2P rules, it's the
> Unserialize code, in particular:
>
>   compat/assumptions.h:52:static_assert(sizeof(int) == 4, "32-bit int
> assumed");
>
>   serialize.h:289:uint64_t ReadCompactSize(Stream& is)
>
>   serialize.h-679-template typename V>
>   serialize.h-680-void Unserialize_impl(Stream& is, prevector& v,
> const V&)
>   serialize.h-681-{
>   serialize.h-682-v.clear();
>   serialize.h:683:unsigned int nSize = ReadCompactSize(is);
>
>   (and other Unserialize_impl implementations)
>
> However, ReadCompactSize throws "size too large" if the return value is
> greater than MAX_SIZE == 0x0200 =~ 33.5M, which prior to the implicit
> cast to 32 bits in Unserialize_impl. And it looks like that check's been
> there since Satoshi...
>
> So as far as I can see, that encoding's just unsupported/invalid, rather
> than equivalent/non-canonical?
>

Thanks for this correction!  I totally missed that MAX_SIZE == 0x0200.
I think I mistook it for SIZE_MAX when reviewing this, or just didn't
notice it at all.

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

Re: [bitcoin-dev] Taproot proposal

[Russell O'Connor via bitcoin-dev]

I have a comment about the 'input_index' of the transaction digest for
taproot signatures.  It is currently listed as 2 bytes.  I think it would
be better to expand that to 4 bytes.
The two byte limit is derived from the block size / weight limit, which
limits the maximum size of a transaction, which in turn, due to a minimum
size of an inputs, places a limit on the maximum number of inputs.

However, I think it is a mistake to mix limits from the block layer into
the transaction layer of the consensus rules.  For example, I believe that,
as it stands currently, if we wanted to hardfork an increase in the block
weight limit, doing so wouldn't have any impact on the transaction layer
and we could transparently manage larger transactions with the current
transaction format [2].  However if we start incorporating the block limits
into the transaction layer, then we run the risk of such a hard fork
needing to also make consensus changes in the transaction
format/interpretation if we wanted to handle larger transaction sizes,
which, while doable, wouldn't be so great.

The current transaction format limits the number of inputs (and the number
of outputs) to 2^32-1 or less [1].  So using 4 bytes for the 'input_index'
will suffice.

Given that adding 2 bytes to the signed transaction digest isn't a big
deal, it's probably better just to keep block limits and transaction limits
separate.

[1]The var-integer field for the number of inputs (and the number of
outputs) in a transaction looks like it should allow upto 2^64-1 inputs;
however this is an illusion.  The P2P rules dictate that these values are
immediately taken modulo 2^32 after decoding.  For example, if the number
of inputs is a var-integer encoding of 0x010001, it is actually just a
non-canonical way of encoding that there is 1 input.  Try this at home!

[2]If we were to hardfork an increase in the block weight limit, we would
probably want to still keep the limit on the size of transactions that
consume legacy UTXOs in order to avoid the quadratic computation problems
that plagues the legacy transaction digest.

On Mon, May 6, 2019 at 2:36 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello everyone,
>
> Here are two BIP drafts that specify a proposal for a Taproot
> softfork. A number of ideas are included:
>
> * Taproot to make all outputs and cooperative spends indistinguishable
> from eachother.
> * Merkle branches to hide the unexecuted branches in scripts.
> * Schnorr signatures enable wallet software to use key
> aggregation/thresholds within one input.
> * Improvements to the signature hashing algorithm (including signing
> all input amounts).
> * Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support
> batch validation.
> * Tagged hashing for domain separation (avoiding issues like
> CVE-2012-2459 in Merkle trees).
> * Extensibility through leaf versions, OP_SUCCESS opcodes, and
> upgradable pubkey types.
>
> The BIP drafts can be found here:
> * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki
> specifies the transaction input spending rules.
> * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki
> specifies the changes to Script inside such spends.
> * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
> is the Schnorr signature proposal that was discussed earlier on this
> list (See
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html
> )
>
> An initial reference implementation of the consensus changes, plus
> preliminary construction/signing tests in the Python framework can be
> found on https://github.com/sipa/bitcoin/commits/taproot. All
> together, excluding the Schnorr signature module in libsecp256k1, the
> consensus changes are around 520 LoC.
>
> While many other ideas exist, not everything is incorporated. This
> includes several ideas that can be implemented separately without loss
> of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT,
> which we're working on as an independent proposal.
>
> The document explains basic wallet operations, such as constructing
> outputs and signing. However, a wide variety of more complex
> constructions exist. Standardizing these is useful, but out of scope
> for now. It is likely also desirable to define extensions to PSBT
> (BIP174) for interacting with Taproot. That too is not included here.
>
> Cheers,
>
> --
> Pieter
> ___
> 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] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

[Russell O'Connor via bitcoin-dev]

Bitcoin Core is somewhat outside my core competence, but the various
OP_PUSHDATA are already multi-byte opcodes and GetOp already has a data
return parameter that is suitable for returning the payload of an immediate
32-byte data variant of OP_SECURETHEBAG.  All that I expect is needed is to
ensure that nowhere else is using a non-empty data-field as a proxy for a
non-empty push operation and fixing any such occurrences if they exist.
(AFAIKT there are only a handful of calls to GetOp).

It is probably worth updating the tapscript implementation to better
prepare it for new uses of OP_SUCCESSx.  Parsing should halt when an
OP_SUCCESSx is encountered, by having GetScriptOp advance the pc to end
after encountering such a code (decoding Script is no longer meaningful
after an OP_SUCCESS is encountered).  However, that means that GetScriptOp
needs to know what version of script it is expected to be parsing.  This
could be done by sending down some versioning flags, possibly by adding a
versioning field to CScript that can be initialized @
https://github.com/sipa/bitcoin/blob/7ddc7027b2cbdd11416809400c588e585a8b44ed/src/script/interpreter.cpp#L1679
or some other mechanism (and at the same time perhaps having GetSigOpCount
return 0 for tapscript, since counting sigops is not really meaningful in
tapscript). There are probably other reasonable approaches too (e.g your
option 2 below).  I could write some code to illustrate what I'm thinking
if you feel that would be helpful and I do think such changes around
OP_SUCCESS should be implemented regardless of whether we move forward with
OP_SECURETHEBAG or not.

It is probably worth doing this properly the first time around if we are
going to do it at all.

P.S. OP_RESERVED1 has been renamed to OP_SUCCESS137 in bip-tapscript.


>
> On Mon, Jun 24, 2019 at 6:47 PM Jeremy  wrote:

> I agree in principal, but I think that's just a bit of 'how things are'
> versus how they should be.
>
> I disagree that we get composability semantics because of OP_IF. E.g., the
> script "OP_IF  " and "OP_END" are two scripts that separately are
> invalid as parsed, but together are valid. OP_IF already imposes some
> lookahead functionality... but as I understand it, it may be feasible to
> get rid of OP_IF for tapscripts anyways. Also in this bucket are P2SH and
> segwit, which I think breaks this because the concat of two p2sh scripts or
> segwit scripts is not the same as them severally.
>
> I also think that the OP_SECURETHEBAG use of pushdata is a backwards
> compatible hack: we can always later redefine the parser to parse
> OP_SECURETHEBAG as the 34 byte opcode, recapturing the purity of the
> semantics. We can also fix it to not use an extra byte in a future tapleaf
> version.
>

> In any case, I don't disagree with figuring out what patching the parser
> to handle multibyte opcodes would look like. If that sort of upgrade-path
> were readily available when I wrote this, it's how I would have done it.
> There are two approaches I looked at mostly:
>
> 1) Adding flags to GetOp to change how it parses
>   a) Most of the same code paths used for new and old script
>   b) Higher risk of breaking something in old script style/downstream
>   c) Cleans up only one issue (multibyte opcodes) leaves other warts in
> place
>   d) less bikesheddable design (mostly same as old script)
>   e) code not increased in size
> 2) Adding a completely new interpreter for Tapscript
>   a) Fork the existing interpreter code
>   b) For all places where scripts are run, switch based on if it is
> tapscript or not
>   c) Can clean up various semantics, can even do fancier things like
> huffman encode opcodes to less than a byte
>   d) Can clearly separate parsing the script from executing it
>   e) Can improve versioning techniques
>   f) Low risk of breaking something in old script style/downstream
>   g) Increases amount of code substantially
>   h) Bikesheddable design (everything is on the table).
>   i) probably a better general mechanism for future changes to script
> parsing, less consensus risk
>   j) More compatible with templated script as well.
>
> If not clear, I think that 2 is probably a better approach, but I'm
> worried that 2.h means this would take a much longer time to implement.
>
> 2 can be segmented into two components:
>
> 1) the architecture of script parser versioning
> 2) the actual new script version
>
> I think that component 1 can be relatively non controversial, thankfully,
> using tapleaf versions (the architecture question is more around code
> structure). A proof of concept of this would be to have a fork that uses
> two independent, but identical, script parsers.
>
> Part two of this plan would be to modify one of the versions
> substantially. I'm not sure what exists on the laundry list, but I think it
> would be possible to pick a few worthwhile cleanups. E.g.:
>
> 1) Multibyte opcodes
> 2) Templated scripts
> 3) Huffman Encoding opcodes
> 4) OP_IF handling (maybe 

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

[Russell O'Connor via bitcoin-dev]

I suspect that your conjecture is true.  And given that it is plausible
that we would want to add an opcode to tweak public keys, it seems like a
reason design to avoid accidental covenants.
(That said, I strongly prefer that the SECURETHEBAG data be the 32-bytes
immediately following the opcode rather than a OP_PUSHDATA, and I'd be
willing to help code this up (see below)).

On Mon, Jun 24, 2019 at 2:07 PM Jeremy  wrote:

> Do you think the following hypothesis is more or less true:
>
> H: There is no set of pure extensions* to script E such that enabling E
> and OP_SECURETHEBAG as proposed enables recursive covenants, but E alone
> does not enable recursive covenants?
>
> * Of course there are things that specifically are specifically designed
> to switch on if OP_SECURETHEBAG, so pure means normal things like OP_CAT
> that are a function of the arguments on the stack or hashed txn data.
>
> This is the main draw of the design I proposed, it should be highly
> improbable or impossible to accidentally introduce more behavior than
> intended with a new opcode.
>
> I think that given that H is not true for the stack reading version of the
> opcode, we should avoid doing it unless strongly motivated, so as to permit
> more flexibility for which opcodes we can add in the future without
> introducing recursion unless it is explicitly intended.
>

On Sat, Jun 1, 2019 at 12:47 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> A particularly useful topic of discussion is how best to eliminate the
> PUSHDATA and treat OP_SECURETHEBAG like a pushdata directly. I thought
> about how the interpreter works and is implemented and couldn't come up
> with something noninvasive.
>

We shouldn't be using the complexity of the changes to the Bitcoin Core a
measure of the complexity of a proposal.  That is looking the issue from
the wrong side.  If we measure the complexity of Script proposals by how
hard it is to change Bitcoin Core, what will happen is more and more of the
incidental details of Bitcoin Core's implementation will be pulled into the
semantics of Script (e.g. the fact that surrounding opcode values are
readily available in Bitcoin Core's particular implementation of its Script
interpreter).  Instead we should use the complexity of how hard it is to
reason about the new Script semantics.

The peeking semantics of OP_SECURETHEBAG is particularly awful because it
more-or-less breaks the fact that Bitcoin Script can be decomposed into
individual units of "opcodes" whose semantics and be individually
described, and it harms the composability of Bitcoin Script where you can
divide the script between any opcodes and the semantics of the
concatenation of those two scripts is simply the composition of the
semantics of the two halves.  (For those interested in formal semantics,
what we have here is a monoid homomorphism from list of opcodes (syntax) to
stack transformation functions (with side-effects) under (Kleisli)
composition (semantics).) Being able to decompose a Bitcoin Script this way
and reasoning about components is how one would reason about Bitcoin Script
in practice.  (Technically the structure is more involved than a list of
opcodes due to OP_IF, and instead you get a railroad diagram
).

Putting the 32 bytes of data required by OP_SECURETHEBAG immediately after
the opcode, like how OP_PUSHDATA* works, is a superior design choice.  It
lets us treat the opcodes and its immediate data as an atomic unit when
reasoning about Script and removes the need to define what happens when
OP_SECURETHEBAG is not followed by an OP_PUSDATA.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

[Russell O'Connor via bitcoin-dev]

OP_SECURETHEBAG doesn't include the script being executed (i.e the
scriptPubKey specified in the output that is redeemed by this input) in its
hash like ordinary signatures do
<https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1271>.
Of course, this ScriptPubKey is indirectly committed to through the input's
prevoutpoint.  However Script isn't able to reconstruct this script being
executed from the prevoutpoint in tapscript without an implementation of
public key tweeking in Bitcoin Script.

On Sun, Jun 23, 2019 at 2:41 AM Jeremy Rubin 
wrote:

> Can you clarify this comment?
>
> We do in fact commit to the script and scriptsig itself (not the witness
> stack) in OP_SECURETHEBAG (unless I'm missing what you meant)?
>
> On Thu, Jun 20, 2019, 10:59 AM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Just to be clear, while OP_CHECKTXDIGESTVERIFY would enable this style
>> of covenants if it pulled data from the stack, the OP_SECURETHEBAG
>> probably cannot create covenants even if it were to pull the data from the
>> stack unless some OP_TWEEKPUBKEY operation is added to Script because the
>> "commitment of the script itself" isn't part of the OP_SECURETHEBAG.
>>
>> So with regards to OP_SECURETHEBAG, I am also "not really seeing any
>> reason to complicate the spec to ensure the digest is precommitted as part
>> of the opcode."
>>
>> On Thu, Jun 6, 2019 at 3:33 AM ZmnSCPxj via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Good morning aj,
>>>
>>>
>>> Sent with ProtonMail Secure Email.
>>>
>>> ‐‐‐ Original Message ‐‐‐
>>> On Wednesday, June 5, 2019 5:30 PM, Anthony Towns via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>> > On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev wrote:
>>> >
>>> > > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*.
>>> >
>>> > I think you could generalise that slightly and make it fit in
>>> > with the existing opcode naming by calling it something like
>>> > "OP_CHECKTXDIGESTVERIFY" and pull a 33-byte value from the stack,
>>> > consisting of a sha256 hash and a sighash-byte, and adding a new
>>> sighash
>>> > value corresponding to the set of info you want to include in the hash,
>>> > which I think sounds a bit like "SIGHASH_EXACTLY_ONE_INPUT |
>>> SIGHASH_ALL"
>>> >
>>> > FWIW, I'm not really seeing any reason to complicate the spec to ensure
>>> > the digest is precommitted as part of the opcode.
>>> >
>>>
>>> I believe in combination with `OP_LEFT` and `OP_CAT` this allows
>>> Turing-complete smart contracts, in much the same way as
>>> `OP_CHECKSIGFROMSTACK`?
>>>
>>> Pass in the spent transaction (serialised for txid) and the spending
>>> transaction (serialised for sighash) as part of the witness of the spending
>>> transaction.
>>>
>>> Script verifies that the spending transaction witness value is indeed
>>> the spending transaction by `OP_SHA256  OP_SWAP OP_CAT
>>> OP_CHECKTXDIGESTVERIFY`.
>>> Script verifies the spent transaction witness value is indeed the spent
>>> transaction by hashing it, then splitting up the hash with `OP_LEFT` into
>>> bytes, and comparing the bytes to the bytes in the input of the spending
>>> transaction witness value (txid being the bytes in reversed order).
>>>
>>> Then the Script can extract a commitment of itself by extracting the
>>> output of the spent transaction.
>>> This lets the Script check that the spending transaction also pays to
>>> the same script.
>>>
>>> The Script can then access a state value, for example from an
>>> `OP_RETURN` output of the spent transaction, and enforce that a correct
>>> next-state is used in the spending transaction.
>>> If the state is too large to fit in a standard `OP_RETURN`, then the
>>> current state can be passed in as a witness and validated against a hash
>>> commitment in an `OP_RETURN` output.
>>>
>>> I believe this is the primary reason against not pulling data from the
>>> stack.
>>>
>>> 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
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

[Russell O'Connor via bitcoin-dev]

Just to be clear, while OP_CHECKTXDIGESTVERIFY would enable this style of
covenants if it pulled data from the stack, the OP_SECURETHEBAG probably
cannot create covenants even if it were to pull the data from the stack
unless some OP_TWEEKPUBKEY operation is added to Script because the
"commitment of the script itself" isn't part of the OP_SECURETHEBAG.

So with regards to OP_SECURETHEBAG, I am also "not really seeing any reason
to complicate the spec to ensure the digest is precommitted as part of the
opcode."

On Thu, Jun 6, 2019 at 3:33 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning aj,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, June 5, 2019 5:30 PM, Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev wrote:
> >
> > > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*.
> >
> > I think you could generalise that slightly and make it fit in
> > with the existing opcode naming by calling it something like
> > "OP_CHECKTXDIGESTVERIFY" and pull a 33-byte value from the stack,
> > consisting of a sha256 hash and a sighash-byte, and adding a new sighash
> > value corresponding to the set of info you want to include in the hash,
> > which I think sounds a bit like "SIGHASH_EXACTLY_ONE_INPUT | SIGHASH_ALL"
> >
> > FWIW, I'm not really seeing any reason to complicate the spec to ensure
> > the digest is precommitted as part of the opcode.
> >
>
> I believe in combination with `OP_LEFT` and `OP_CAT` this allows
> Turing-complete smart contracts, in much the same way as
> `OP_CHECKSIGFROMSTACK`?
>
> Pass in the spent transaction (serialised for txid) and the spending
> transaction (serialised for sighash) as part of the witness of the spending
> transaction.
>
> Script verifies that the spending transaction witness value is indeed the
> spending transaction by `OP_SHA256  OP_SWAP OP_CAT
> OP_CHECKTXDIGESTVERIFY`.
> Script verifies the spent transaction witness value is indeed the spent
> transaction by hashing it, then splitting up the hash with `OP_LEFT` into
> bytes, and comparing the bytes to the bytes in the input of the spending
> transaction witness value (txid being the bytes in reversed order).
>
> Then the Script can extract a commitment of itself by extracting the
> output of the spent transaction.
> This lets the Script check that the spending transaction also pays to the
> same script.
>
> The Script can then access a state value, for example from an `OP_RETURN`
> output of the spent transaction, and enforce that a correct next-state is
> used in the spending transaction.
> If the state is too large to fit in a standard `OP_RETURN`, then the
> current state can be passed in as a witness and validated against a hash
> commitment in an `OP_RETURN` output.
>
> I believe this is the primary reason against not pulling data from the
> stack.
>
> 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] [PROPOSAL] Emergency RBF (BIP 125)

[Russell O'Connor via bitcoin-dev]

On Sat, Jun 8, 2019 at 11:59 PM Rusty Russell  wrote:

> "Russell O'Connor"  writes:
> > Hi Rusty,
> >
> > On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> The new "emergency RBF" rule:
> >>
> >>  6. If the original transaction was not in the first 4,000,000 weight
> >> units of the fee-ordered mempool and the replacement transaction is,
> >> rules 3, 4 and 5 do not apply.
> >>
> >> This means:
> >>
> >> 3. This proposal does not open any significant new ability to RBF spam,
> >>since it can (usually) only be used once.  IIUC bitcoind won't
> >>accept more that 100 descendents of an unconfirmed tx anyway.
> >>
> >
> > Is it not possible for Alice to grief Bob's node by alternating RBFing
> two
> > transactions, each one placing itself at the bottom of Bob's top
> 4,000,000
> > weight mempool which pushes the other one below the top 4,000,000 weight,
> > and then repeating with the other transaction?  It might be possible to
> > amend this proposal to partially mitigate this.
>
> Good point.  This will cost Alice approximately one tx every block, but
> that may still be annoying.  My intuition says it's hard to play these
> games across swathes of non-direct peers, since mempools are in constant
> flux and propagation is a bit random.
>
> What mitigations were you thinking?
>

For example,  "If the original transaction was not in the first 4,000,000
weight units of the fee-ordered mempool and the replacement transaction is
in the first 2,000,000 weight units" might adequately address the issue.
There are probably other ways as well.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)

[Russell O'Connor via bitcoin-dev]

Hi Rusty,

On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The new "emergency RBF" rule:
>
>  6. If the original transaction was not in the first 4,000,000 weight
> units of the fee-ordered mempool and the replacement transaction is,
> rules 3, 4 and 5 do not apply.
>
> This means:
>
> 3. This proposal does not open any significant new ability to RBF spam,
>since it can (usually) only be used once.  IIUC bitcoind won't
>accept more that 100 descendents of an unconfirmed tx anyway.
>

Is it not possible for Alice to grief Bob's node by alternating RBFing two
transactions, each one placing itself at the bottom of Bob's top 4,000,000
weight mempool which pushes the other one below the top 4,000,000 weight,
and then repeating with the other transaction?  It might be possible to
amend this proposal to partially mitigate this.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

[Russell O'Connor via bitcoin-dev]

On Sat, Jun 1, 2019 at 12:47 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi All,
>
> OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*.
> OP_SECURETHEBAG does more or less the same thing, but fixes malleability
> issues and lifts the single output restriction to a known number of inputs
> restriction.
>
> OP_CHECKOUTPUTSVERIFY had some issues with malleability of version and
> locktime. OP_SECURETHEBAG commits to both of these values.
>

Can you elaborate a bit more on what the issues were?


> OP_SECURETHEBAG also lifts the restriction that OP_CHECKOUTPUTSVERIFY had
> to be spent as only a single input, and instead just commits to the number
> of inputs. This allows for more flexibility, but keeps it easy to get the
> same single output restriction.
>
> BIP:
> https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secure-the-bag.mediawiki
> Implementation: https://github.com/JeremyRubin/bitcoin/tree/secure_the_bag
>
> A particularly useful topic of discussion is how best to eliminate the
> PUSHDATA and treat OP_SECURETHEBAG like a pushdata directly. I thought
> about how the interpreter works and is implemented and couldn't come up
> with something noninvasive.
>

I'm not a Core developer but from what I understand, I'd be inclined to to
treat OP_SECURETHEBAG as with an immediate 32-byte parameter by modifying
GetScriptOp to return the 32-byte parameter through pvchRet.

bool GetScriptOp(CScriptBase::const_iterator& pc,
CScriptBase::const_iterator end, opcodetype& opcodeRet,
std::vector* pvchRet)
{
opcodeRet = OP_INVALIDOPCODE;
if (pvchRet)
pvchRet->clear();
if (pc >= end)
return false;

// Read instruction
if (end - pc < 1)
return false;
unsigned int opcode = *pc++;

// Immediate operand
if (opcode <= OP_PUSHDATA4)
{
// ...
}

if (opcode == OP_SECURETHEBAG) {
if (end - pc < 0 || (unsigned int)(end - pc) < 32)
return false;
if (pvchRet)
pvchRet->assign(pc, pc + 32);
pc += 32;
}

opcodeRet = static_cast(opcode);
return true;
}

and go from there.

Thank you for your review and discussion,
>
> Jeremy
>
> * Plus the name is better
>
> ___
> 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] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

[Russell O'Connor via bitcoin-dev]

On Mon, May 27, 2019 at 3:21 AM Anthony Towns  wrote:

> On Wed, May 22, 2019 at 05:01:21PM -0400, Russell O'Connor via bitcoin-dev
> wrote:
> > Bitcoin Script appears designed to be a flexible programmable system that
> > provides generic features to be composed to achieve various purposes.
>
> Counterpoint: haven't the flexibly designed parts of script mostly been
> a failure -- requiring opcodes to be disabled due to DoS vectors or
> consensus bugs, and mostly not being useful in practice where they're
> still enabled in BTC or on other chains where they have been re-enabled
> (eg, Liquid and BCH)?
>

You may have a point.  However, I'm still inclined to think that problem is
that you want some subset of concatenation, arithmetic, CHECKDATASIG,
transaction reflection and/or covenants in order to create particularly
useful programs.

A while ago, I was designing a moderately sophisticated Script for Elements
Alpha to see if I could implement a toy game, but ultimately I was thwarted
due to the fact that Elements Alpha didn't support multiplication.
I did briefly consider using repeated additions and nested if statements to
implement multiplication since I was expecting my numbers to be 11 or less,
but ultimately I decided to just continue my work on an alternative to
Script rather than trying to work around the missing multiplication.


> > Instead, I propose that, for the time being, we simply implement OP_CAT
> and
> > OP_CHECKSIGFROMSTACKVERIFY.
>
> FWIW, I'd like to see CAT enabled, though I'm less convinced about a
> CHECKSIG that takes the message from the stack. I think CAT's plausibly
> useful in practice, but a sig against data from the stack seems more
> useful in theory than in practice. Has it actually seen use on BCH or
> Liquid, eg?  (Also, I think BCH's name for that opcode makes more sense
> than Elements' -- all the CHECKSIG opcodes pull a sig from the stack,
> after all)
>
> > * Transaction introspection including:
> > + Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned simply
> by the
> > nature of the construction.
>
> I think simulating an ANYPREVOUT sig with a data signature means checking:
>
> S1 P CHECKSIG -- to check S1 is a signature for the tx
>
> S1 H_TapSighash(XAB) P CHECKDATASIG
>  -- to pull out the tx data "X", "A", "B")
>
> S2 H_TapSighash(XCB) Q CHECKDATASIG
>  -- for the ANYPREVOUT sig, with A changed to C to
> avoid committing to prevout info
>
> X SIZE 42 EQUALVERIFY
> B SIZE 47 EQUALVERIFY
>  -- to make sure only C is replaced from "XCB"
>
> So to get all those conditions checked, I think you could do:
>
>P 2DUP TOALT TOALT CHECKSIGVERIFY
>SIZE 42 EQUALVERIFY
>"TapSighash" SHA256 DUP CAT SWAP CAT TOALT
>SIZE 47 EQUALVERIFY TUCK
>CAT FROMALT TUCK SWAP CAT SHA256 FROMALT SWAP FROMALT
>CHECKDATASIGVERIFY
>SWAP TOALT SWAP CAT FROMALT CAT SHA256 Q CHECKDATASIG
>
> Where the stack elements are, from top to bottom:
>
>S1: (65B) signature by P of tx
>X:  (42B) start of TapSighash spec
>B:  (47B) end of TapSighash spec (amount, nSequence, tapleaf_hash,
>  key_version, codesep_pos)
>A:  (73B) middle of TapSighash spec dropped for ANYPREVOUT (spend_type,
>  scriptPubKey and outpoint)
>C:   (1B) alternate middle (different spend_type)
>S2: (64B) signature of "XCB" by key Q
>
> So 298B for the witness data, and 119B or so for the script (if I've not
> made mistakes), versus "P CHECKSIGVERIFY Q CHECKSIG" and S2 and S1 on
> the stack, for 132B of witness data and 70B of script, or half that if
> the chaperone requirement is removed.
>

I haven't checked your details but the above looks about correct to me.

So what I was thinking is that we could add CHECKDATASIG first, and then
people could get started on actually using ANYPREVOUT in practice and we
can take our time to debate the merits of the chaperone vs non-chaperone,
and possibly learn something about actual use before making a decision.
There is no doubt that using ANYPREVOUT directly uses less weight, but they
seem close enough to that it the simulation is usable, though perhaps far
enough apart that we would want to eventually add ANYPREVOUT.  However, do
keep in mind that our goal is not to minimize the weight of specific
redemption policies.  The weight of implementing any particular redemption
policy in Script is somewhat arbitrary to begin with anyways, being
dependent on the choices made for the Script language operations and its
encoding.  Again, if our goal were to minimize weight for specific
redemption policies we should abandon SCRIPT and directly use a language
similar to Mi

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

[Russell O'Connor via bitcoin-dev]

Allowing multiple inputs is certainly better than the 1 restriction COSHV.

However, I agree on your preference for a RISC+CISC approach.  Which is why
instead of COSHV or CHECK_TXID_TEMPLACE_DATA we should do the more RISC-y
thing and begin adding transaction reflection primitives, starting with
OP_NUMINPUTS and OP_PUSHOUTPUTSHASH.  Nothing bad will happen by pushing
the OUTPUTSHASH onto the stack, and we won't even get recursive covenants
with just these transaction reflection primitives in tapscript.

On Fri, May 24, 2019 at 9:08 PM Jeremy  wrote:

> What do you think about having it be OP_CHECK_TXID_TEMPLATE_DATA where the
> hash checked is the TXID of the transaction with the inputs set to ...
> (maybe appended to the fee paid)?
>
> This allows for a variable number of inputs to be allowed (e.g., one, two,
> etc). This also fixes potential bugs around TXID malleability for lightning
> like setups (Greg and I discussed in wizards about version malleability).
>
> Allowing multiple inputs is great for structuring more complex contracts
> with multiple nodes paying into the same covenantted transaction.
>
> Also I personally prefer a RISC+CISC approach -- we should enable the
> common paths easily as they are known (didn't you come up with jets?) and
> improve security for API users, but also piecemeal enable features in
> script to allow for experimentation or custom contracts.
> --
> @JeremyRubin 
> 
>
>
> On Fri, May 24, 2019 at 4:15 PM Russell O'Connor 
> wrote:
>
>> In order of escalating scope of amendments to OP_COSHV, I suggest
>>
>> 1) Peeking at surrounding data surrounding data should definitely be
>> replaced by a pushdata-like op-code that uses the subsequent 32-bytes
>> directly.  The OP_SUCCESSx upgrade path specifically allows for this, and
>> avoids complicating the semantics Bitcoin Script.
>> 2) Furthermore, the number-of-input-verification and the
>> outputhash-verification operations ought to be split into different opcodes
>> as they are logically unrelated.
>> 3) Better still, we should instead implement the transaction reflection
>> operations of OP_PUSHOUTPUTHASH and OP_NUMINPUTS that puts the outputhash
>> and number of inputs respectively onto the stack.  Recursive covenants
>> appear to be effectively impossible without either an OP_TWEEKPUBKEY or an
>> OP_PUSHSCRIPTPUBKEY so the effort your proposal goes through to guard
>> against placing an arbitrary outputhash onto the stack appears to be wasted
>> effort to me.
>> 4) If we anticipate adding OP_CHECKSIGFROMSTACKVERIFY, then we should
>> most definitely prefer (3) instead of OP_COSHV, if we still feel the need
>> to do anything at all.  It is probably best to have both
>> OP_CHECKSIGFROMSTACKVERIFY and transaction reflection operations of
>> OP_PUSHOUTPUTHASH and OP_NUMINPUTS but I think I would be fine with just
>> OP_CHECKSIGFROMSTACKVERIFY as well.
>>
>> On the other hand, if we are serious about preferring less per-block
>> bandwidth over reusable primitive opcodes for programming, then we should
>> instead abandon the RISC-style Bitcoin Script and instead add an
>> alternative CISC-style taproot leaf type that directly provides (a
>> conjunction of) the various popular common policies: channel opening,
>> channel factories, coinjoins, hashlocks, timelocks, congestion control
>> etc.  Segwit v0 already implements this CISC-style for the single most
>> popular policy: single signature verification.
>>
>> On Fri, May 24, 2019 at 4:51 PM Jeremy  wrote:
>>
>>> Hi Russell,
>>>
>>> Thanks for this detailed comparison. The COSHV BIP does include a brief
>>> comparison to OP_CHECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more
>>> detailed.
>>>
>>>
>>> I think that the power from CHECKSIGFROMSTACKVERIFY is awesome. It's
>>> clearly one of the more flexible options available and would enable a
>>> multitude of new use cases.
>>>
>>> When I originally presented my work on congestion control at Jan 2017
>>> BPASE, I also discussed it as an option for covenants. Unfortunately I
>>> think it may be on the edge of too powerful -- there are a lot of use cases
>>> and implications from having a potentially recursive covenant. If you see
>>> my response to Matt in the OP_COSHV BIP thread I classify it as enabling a
>>> non-computationally enumerable set of restrictions.
>>>
>>> I think also from a developer point of view working with OP_COSHV is
>>> much much simpler (maybe this can be abstracted) which will lead to
>>> increased adoption. OP_COSHV also uses less per-block bandwidth which also
>>> makes it preferable for a measure intended to decongest blocks. Do you know
>>> the exact byte cost for OP_CHECKSIGFROMSTACK? OP_COSHV scripts, with
>>> templating changes to taproot, can be a single byte. OP_COSHV also has less
>>> potential to have a negative interaction with future opcodes we may want
>>> like OP_PUBKEYTWEAK. While we're getting to an exact spec for 

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

[Russell O'Connor via bitcoin-dev]

In order of escalating scope of amendments to OP_COSHV, I suggest

1) Peeking at surrounding data surrounding data should definitely be
replaced by a pushdata-like op-code that uses the subsequent 32-bytes
directly.  The OP_SUCCESSx upgrade path specifically allows for this, and
avoids complicating the semantics Bitcoin Script.
2) Furthermore, the number-of-input-verification and the
outputhash-verification operations ought to be split into different opcodes
as they are logically unrelated.
3) Better still, we should instead implement the transaction reflection
operations of OP_PUSHOUTPUTHASH and OP_NUMINPUTS that puts the outputhash
and number of inputs respectively onto the stack.  Recursive covenants
appear to be effectively impossible without either an OP_TWEEKPUBKEY or an
OP_PUSHSCRIPTPUBKEY so the effort your proposal goes through to guard
against placing an arbitrary outputhash onto the stack appears to be wasted
effort to me.
4) If we anticipate adding OP_CHECKSIGFROMSTACKVERIFY, then we should most
definitely prefer (3) instead of OP_COSHV, if we still feel the need to do
anything at all.  It is probably best to have both
OP_CHECKSIGFROMSTACKVERIFY and transaction reflection operations of
OP_PUSHOUTPUTHASH and OP_NUMINPUTS but I think I would be fine with just
OP_CHECKSIGFROMSTACKVERIFY as well.

On the other hand, if we are serious about preferring less per-block
bandwidth over reusable primitive opcodes for programming, then we should
instead abandon the RISC-style Bitcoin Script and instead add an
alternative CISC-style taproot leaf type that directly provides (a
conjunction of) the various popular common policies: channel opening,
channel factories, coinjoins, hashlocks, timelocks, congestion control
etc.  Segwit v0 already implements this CISC-style for the single most
popular policy: single signature verification.

On Fri, May 24, 2019 at 4:51 PM Jeremy  wrote:

> Hi Russell,
>
> Thanks for this detailed comparison. The COSHV BIP does include a brief
> comparison to OP_CHECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more
> detailed.
>
>
> I think that the power from CHECKSIGFROMSTACKVERIFY is awesome. It's
> clearly one of the more flexible options available and would enable a
> multitude of new use cases.
>
> When I originally presented my work on congestion control at Jan 2017
> BPASE, I also discussed it as an option for covenants. Unfortunately I
> think it may be on the edge of too powerful -- there are a lot of use cases
> and implications from having a potentially recursive covenant. If you see
> my response to Matt in the OP_COSHV BIP thread I classify it as enabling a
> non-computationally enumerable set of restrictions.
>
> I think also from a developer point of view working with OP_COSHV is much
> much simpler (maybe this can be abstracted) which will lead to increased
> adoption. OP_COSHV also uses less per-block bandwidth which also makes it
> preferable for a measure intended to decongest blocks. Do you know the
> exact byte cost for OP_CHECKSIGFROMSTACK? OP_COSHV scripts, with templating
> changes to taproot, can be a single byte. OP_COSHV also has less potential
> to have a negative interaction with future opcodes we may want like
> OP_PUBKEYTWEAK. While we're getting to an exact spec for the features we
> want in Bitcoin scripting, it's hard to sign on to OP_CHECKSIGFROMSTACK
> unless there's an exact specification which makes us confident we're
> hitting all the points.
>
> If the main complaint about OP_COSHV is that it peeks at surrounding data,
> it's also possible to implement it more closely to a multi-byte pushdata
> opcode or do the template optimization.
>
> Lastly, as I have previously noted, OP_LEFT is probably safer to implement
> than OP_CAT and should be more efficient for OP_CHECKSIGFROMSTACK scripts.
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

[Russell O'Connor via bitcoin-dev]

On Wed, May 22, 2019 at 5:01 PM Russell O'Connor 
wrote:

> In concert, these two operations enable:
>
> * Oracle signature verification, including discrete log contracts.
>

Jonas informs me that I've misunderstood how discreet log contracts work.
The DLC signatures are not directly checked by Script and do not rely on
CHECKSIGFROMSTACK.  I apologize for my hasty literature review.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

[Russell O'Connor via bitcoin-dev]

Hello ZmnSCPxj,

I agree that adding OP_CHECKSIGFROMSTACK doesn't preclude adding shortcuts
such as `SIGHASH_ANYPREVOUT` and `OP_CHECKOUTPUTSHASHVERIFY`, and I agree
we ought to support such operations directly, especially if we see
widespread use of these constructions in practice.

I think it is desirable to add OP_CHECKSIGFROMSTACK for its direct purposes
of enabling oracle verification and discreet log contracts.  Moreover, it
would be better decide if we do or do not want to do this first, because
whether or not we chose to implement a general OP_CHECKSIGFROMSTACK will
influence the design of these other proposals.

For example, if we choose to deploy OP_CHECKSIGFROMSTACK, then the design
of OP_CHECKOUTPUTSHASHVERIFY ought to be simplified to OP_PUSHOUTPUTHASH
and OP_PUSHNUMINPUTS (etc.) because the proposal would no longer be
extending the expressiveness of Bitcoin Script.  And while
OP_CHECKSIGFROMSTACK doesn't directly address whether SIGHASH_ANYPREVOUT
should be with or without a chaperone (as the simulated version with
OP_CHECKSIGFROMSTACK is necessarily chaperoned), we might get an
opportunity to learn if users are willing to take advantage of the
chaperone, or whether they rather bypass it by using a short well-known
pubkey: (e.g.
0x02003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63)
and/or similar short signatures if we deploy OP_CHECKSIGFROMSTACK first.

Since most of the "scary" recursive convents are not available with
OP_CHECKSIGFROMSTACK within taproot (without further extensions), the
OP_CHECKSIGFROMSTACK proposal now has quite different consequences than
before.

On Thu, May 23, 2019 at 12:59 PM ZmnSCPxj  wrote:

> Good morning Russell,
>
> While I am sympathetic to this argument from first principles, as I
> understand it, it requires that provided witness inputs will become larger,
> compared to "shortcuts" like `SIGHASH_ANYPREVOUT` and
> `OP_CHECKOUTPUTSHASHVERIFY`.
>
> For instance, to simulate `SIGHASH_ANYPREVOUT` with `OP_CAT` and
> `OP_CHECKSIGFROMSTACK`, I would effectively split the unsigned transaction
> into its "inputs" and "outputs" part, concat them and use
> `OP_CHECKSIGFROMSTACK` on the chaperone signature, and also use a normal
> `OP_CHECKSIGVERIFY` on that same chaperone signature, then dup the
> "outputs" part and use `OP_CHECKSIGFROMSTACK` on the "any
> prevout"/"noinput" signature.
> I would effectively give the transaction to itself as part of the witness,
> and further, I would also have to very carefully write the script
> (admittedly the writing of the template could be done once, but it would
> require far more review than simple usages of the "limited" operations like
> `SIGHASH_ANYPREVOUT`).
> So my witness stack would contain two signatures, and a duplicate of the
> transaction itself, plus a very much complicated script, whereas use of
> `SIGHASH_ANYPREVOUT` just requires two signatures and a script not much
> longer than pre-Schnorr multisig scripts.
>
>
> It seems to me desirable, to try to reduce bandwidth consumption on the
> Bitcoin blockchain, including witness data.
> Indeed, I had thought the whole exercise of putting `OP_CHECKSIGFROMSTACK`
> in a federated sidechain (Elements/Liquid) was to try to identify common
> patterns of usage for that opcode, and *then* to propose those common
> patterns as specific "optimized" opcodes as a sort of "jet" for Bitcoin
> itself (but not `OP_CHECKSIGFROMSTACK` itself).
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev