Nostr notes by Russell O'Connor [ARCHIVE]

📅 Original date posted:2023-08-21 🗒️ Summary of this ...

2023-08-22T14:20:55Z

In reply to nevent1q…8jzx
_________________________

📅 Original date posted:2023-08-21
🗒️ Summary of this message: Banning arbitrary data will lead to actors encoding their data within public keys, making it indistinguishable from random data. Users will find ways to tunnel their data through innocent-looking public key data. Counterparty has previously encoded their data within public key data.
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230821/9f2cda38/attachment.html>;

📅 Original date posted:2023-02-22 🗒️ Summary of this ...

2023-06-07T23:19:47Z

In reply to nevent1q…40c0
_________________________

📅 Original date posted:2023-02-22
🗒️ Summary of this message: Codex32 allows for error correction aided by a computer, but it is more difficult to do by hand. It does not natively support nested SSSS like SLIP39.
📝 Original message:On Sun, Feb 19, 2023 at 3:13 PM David A. Harding via bitcoin-dev <
bitcoin-dev at 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 SSSS
> 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
secret data.

There are three main vectors a hardware wallet can try to communicate that
I am aware of:

1. Compromise at seed/master secret (or in this case shares of the master
secret) during generation time.
2. Lie about public keys at public key generation time.
3. Exfiltrate data though signature data or otherwise during signature
generation time.

#3 is largely mitigated through using anti-exfil signing and air gapping
the hardware wallet (e.g. using QR codes, or using RS-232
<https://en.wikipedia.org/wiki/RS-232>; if you consider that air gaping).
Using multiple wallets from different vendors doing deterministic signing
is another possibility, but I consider the method deprecated in favour of
anti-exfil.

Addressing #1 is where codex32 lies, by taking master secret handling
functions out of the hardware wallet.

My understanding is that it is difficult for digital hardware, which tries
very hard to be deterministic, to generate randomness, especially for
isolated hardware devices like hardware wallets.
Also it is hard for hardware to tell if their hardware random number
generator is broken. Generally I don't trust small pieces of isolated
digital hardware to generate master seeds, even when they are not
malicious. This may just be due to my ignorance of how they operate.

#2 seems to be the hardest issue to address. My current thinking is to
generate addresses on a diverse set of hardware and/or using public
derivations.
Perhaps an alternative to BIP-32 could be designed to make it easy to
generate zero-knowledge proofs of pubkey derivations.

Of course there are other ways for a hardware wallets to exfiltrate data:
The wallet can blink lights, make noise, or it can try to use radio
broadcasts, etc. These other attack vectors seem to require physically
local support, which is a fairly big hurdle to overcome. I suppose even
these vectors could be mitigated through various levels of tinfoil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230222/041a5132/attachment-0001.html>;

📅 Original date posted:2023-02-23 🗒️ Summary of this ...

2023-06-07T23:19:46Z

In reply to nevent1q…3xmk
_________________________

📅 Original date posted:2023-02-23
🗒️ Summary of this message: A simplified procedure for the 1 character "quick check" of Bech32 is proposed, but it has a 3% failure rate and compromises ease of hand computation.
📝 Original message: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 (<current state>, <next input character>) ->
<next state>. 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 <roconnor at blockstream.com>
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
> 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 <roconnor at blockstream.com>
> 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 at lists.linuxfoundation.org> wrote:
>>
>>> On Sun, Feb 19, 2023 at 10:12:51PM +0000, 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230223/0526acda/attachment.html>;

📅 Original date posted:2023-02-23 🗒️ Summary of this ...

2023-06-07T23:19:46Z

In reply to nevent1q…g9g2
_________________________

📅 Original date posted:2023-02-23
🗒️ Summary of this message: Performing 2 character quick checks in 7 different ways is equivalent to a full checksum verification, with prescribed order for accumulating BCH guarantees.
📝 Original message: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 <roconnor at blockstream.com>
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
> 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 <roconnor at blockstream.com>
> 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 at lists.linuxfoundation.org> wrote:
>>
>>> On Sun, Feb 19, 2023 at 10:12:51PM +0000, 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230223/4b73d4e8/attachment-0001.html>;

📅 Original date posted:2023-02-23 🗒️ Summary of this ...

2023-06-07T23:19:45Z

In reply to nevent1q…k8uy
_________________________

📅 Original date posted:2023-02-23
🗒️ Summary of this message: Generators for degree 2 BCH codes are smooth and factor into quadratic and linear components, allowing for partial verification of codex32 strings.
📝 Original message: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 <roconnor at blockstream.com>
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 at lists.linuxfoundation.org> wrote:
>
>> On Sun, Feb 19, 2023 at 10:12:51PM +0000, 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230222/8bca8605/attachment-0001.html>;

📅 Original date posted:2023-02-19 🗒️ Summary of this ...

2023-06-07T23:19:44Z

In reply to nevent1q…u0tc
_________________________

📅 Original date posted:2023-02-19
🗒️ Summary of this message: A potential attack on seed recovery for Bitcoin wallets was discussed, with no current solution available. A MAC-based checksum may be a possible solution.
📝 Original message:On Sun, Feb 19, 2023 at 5:13 PM Andrew Poelstra via bitcoin-dev <
bitcoin-dev at 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 <https://gitea.blesmrt.net/exa/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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230219/7fa702ff/attachment.html>;

📅 Original date posted:2023-02-22 🗒️ Summary of this ...

2023-06-07T23:19:44Z

In reply to nevent1q…u4qn
_________________________

📅 Original date posted:2023-02-22
🗒️ Summary of this message: A simpler approach to verify shares without a computer is suggested for Codex32. A mod N=0 checksum can be used for individual shares or all shares.
📝 Original message: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 at lists.linuxfoundation.org> wrote:

> On Sun, Feb 19, 2023 at 10:12:51PM +0000, 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230222/8b9500fc/attachment.html>;

📅 Original date posted:2023-02-16 🗒️ Summary of this ...

2023-06-07T23:19:39Z

In reply to nevent1q…9urd
_________________________

📅 Original date posted:2023-02-16
🗒️ Summary of this message: Ancient scrolls discovered in Pennsylvania reveal the existence of a secret society devoted to computation in 200 BC, using a system of cryptographic computations.
📝 Original message: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-0000.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-----

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

==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 sensibly be
extended to support secret sharing, has no support for versioning or other
metadata, and has many technical design decisions that make implementation
and interoperability difficult (for example, the use of SHA-512 to derive
seeds, or the use of 11-bit words).

==Specification==

===codex32===

A codex32 string is similar to a Bech32 string defined in [
https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP-0173].
It reuses the base32 character set from BIP-0173, and consists of:

* A human-readable part, which is the string "ms" (or "MS").
* A separator, which is always "1".
* A data part which is in turn subdivided into:
** A threshold parameter, which MUST be a single digit between "2" and "9",
or the digit "0".
*** If the threshold parameter is "0" then the share index, defined below,
MUST have a value of "s" (or "S").
** An identifier consisting of 4 Bech32 characters.
** A share index, which is any Bech32 character. Note that a share index
value of "s" (or "S") is special and denotes the unshared secret (see
section "Unshared Secret").
** A payload which is a sequence of up to 74 Bech32 characters. (However,
see '''Long codex32 Strings''' below for an exception to this limit.)
** A checksum which consists of 13 Bech32 characters as described below.

As with Bech32 strings, a codex32 string MUST be entirely uppercase or
entirely lowercase.
The lowercase form is used when determining a character's value for
checksum purposes.
For presentation, lowercase is usually preferable, but uppercase SHOULD be
used for handwritten codex32 strings.

===Checksum===

The last thirteen characters of the data part form a checksum and contain
no information.
Valid strings MUST pass the criteria for validity specified by the Python3
code snippet below.
The function <code>ms32_verify_checksum</code> must return true when its
argument is the data part as a list of integers representing the characters
converted using the bech32 character table from BIP-0173.

To construct a valid checksum given the data-part characters (excluding the
checksum), the <code>ms32_create_checksum</code> function can be used.

<source lang="python">
MS32_CONST = 0x10ce0795c2fd1e62a

def ms32_polymod(values):
GEN = [
0x19dc500ce73fde210,
0x1bfae00def77fe529,
0x1fbd920fffe7bee52,
0x1739640bdeee3fdad,
0x07729a039cfc75f5a,
]
residue = 0x23181b3
for v in values:
b = (residue >> 60)
residue = (residue & 0x0fffffffffffffff) << 5 ^ v
for i in range(5):
residue ^= GEN[i] if ((b >> i) & 1) else 0
return residue

def ms32_verify_checksum(data):
if len(data) >= 96: # See Long codex32 Strings
return ms32_verify_long_checksum(data)
if len(data) <= 93:
return ms32_polymod(data) == MS32_CONST
return False

def ms32_create_checksum(data):
if len(data) > 80: # See Long codex32 Strings
return ms32_create_long_checksum(data)
values = data
polymod = ms32_polymod(values + [0] * 13) ^ MS32_CONST
return [(polymod >> 5 * (12 - i)) & 31 for i in range(13)]
</source>

===Error Correction===

A codex32 string without a valid checksum MUST NOT be used.
The checksum is designed to be an error correcting code that can correct up
to 4 character substitutions, up to 8 unreadable characters (called
erasures), or up to 13 consecutive erasures.
Implementations SHOULD provide the user with a corrected valid codex32
string if possible.
However, implementations SHOULD NOT automatically proceed with a corrected
codex32 string without user confirmation of the corrected string, either by
prompting the user, or returning a corrected string in an error message and
allowing the user to repeat their action.
We do not specify how an implementation should implement error correction.
However, we recommend that:

* Implementations make suggestions to substitute non-bech32 characters with
bech32 characters in some situations, such as replacing "B" with "8", "O"
with "0", "I" with "l", etc.
* Implementations interpret "?" as an erasure.
* Implementations optionally interpret other non-bech32 characters, or
characters with incorrect case, as erasures.
* If a string with 8 or fewer erasures can have those erasures filled in to
make a valid codex32 string, then the implementation suggests such a string
as a correction.
* If a string consisting of valid Bech32 characters in the proper case can
be made valid by substituting 4 or fewer characters, then the
implementation suggests such a string as a correction.

===Unshared Secret===

When the share index of a valid codex32 string (converted to lowercase) is
the letter "s", we call the string a codex32 secret.
The subsequent data characters in a codex32 secret, excluding the final
checksum of 13 characters, is a direct encoding of a BIP-0032 HD master
seed.

The master seed is decoded by converting the data to bytes:

* Translate the characters to 5 bits values using the bech32 character
table from BIP-0173, most significant bit first.
* Re-arrange those bits into groups of 8 bits. Any incomplete group at the
end MUST be 4 bits or less, and is discarded.

Note that unlike the decoding process in BIP-0173, we do NOT require that
the incomplete group be all zeros.

For an unshared secret, the threshold parameter (the first character of the
data part) is ignored (beyond the fact it must be a digit for the codex32
string to be valid).
We recommend using the digit "0" for the threshold parameter in this case.
The 4 character identifier also has no effect beyond aiding users in
distinguishing between multiple different master seeds in cases where they
have more than one.

===Recovering Master Seed===

When the share index of a valid codex32 string (converted to lowercase) is
not the letter "s", we call the string an codex32 share.
The first character of the data part indicates the threshold of the share,
and it is required to be a non-"0" digit.

In order to recover a master seed, one needs a set of valid codex32 shares
such that:

* All shares have the same threshold value, the same identifier, and the
same length.
* All of the share index values are distinct.
* The number of codex32 shares is exactly equal to the (common) threshold
value.

If all the above conditions are satisfied, the <code>ms32_recover</code>
function will return a codex32 secret when its argument is the list of
codex32 shares with each share represented as a list of integers
representing the characters converted using the bech32 character table from
BIP-0173.

<source lang="python">
bech32_inv = [
0, 1, 20, 24, 10, 8, 12, 29, 5, 11, 4, 9, 6, 28, 26, 31,
22, 18, 17, 23, 2, 25, 16, 19, 3, 21, 14, 30, 13, 7, 27, 15,
]

def bech32_mul(a, b):
res = 0
for i in range(5):
res ^= a if ((b >> i) & 1) else 0
a *= 2
a ^= 41 if (32 <= a) else 0
return res

def bech32_lagrange(l, x):
n = 1
c = []
for i in l:
n = bech32_mul(n, i ^ x)
m = 1
for j in l:
m = bech32_mul(m, (x if i == j else i) ^ j)
c.append(m)
return [bech32_mul(n, bech32_inv[i]) for i in c]

def ms32_interpolate(l, x):
w = bech32_lagrange([s[5] for s in l], x)
res = []
for i in range(len(l[0])):
n = 0
for j in range(len(l)):
n ^= bech32_mul(w[j], l[j][i])
res.append(n)
return res

def ms32_recover(l):
return ms32_interpolate(l, 16)
</source>

===Generating Shares===

If we already have ''t'' valid codex32 strings such that:

* All strings have the same threshold value ''t'', the same identifier, and
the same length
* All of the share index values are distinct

Then we can derive additional shares with the <code>ms32_interpolate</code>
function by passing it a list of exactly ''t'' of these codex32 strings,
together with a fresh share index distinct from all of the existing share
indexes.
The newly derived share will have the provided share index.

Once a user has generated ''n'' codex32 shares, they may discard the
codex32 secret (if it exists).
The ''n'' shares form a ''t'' of ''n'' Shamir's secret sharing scheme of a
codex32 secret.

There are two ways to create an initial set of ''t'' valid codex32 strings,
depending on whether the user already has an existing master seed to split.

====For an existing master seed====

Before generating shares for an existing master seed, it first must be
converted into a codex32 secret, as described above.
The conversion process consists of:

* Choosing a threshold value ''t'' between 2 and 9, inclusive
* Choosing a 4 bech32 character identifier
** We do not define how to choose the identifier, beyond noting that it
SHOULD be distinct for every master seed the user may need to disambiguate.
* Setting the share index to "s"
* Setting the payload to a Bech32 encoding of the master seed, padded with
arbitrary bits
* Generating a valid checksum in accordance with the Checksum section

Along with the codex32 secret, the user must generate ''t''-1 other codex32
shares, each with the same threshold value, the same identifier, and a
distinct share index.
The set of share indexes may be chosen arbitrarily.
The payload of each of these codex32 shares is chosen uniformly at random
such that it has the same length as the payload of the codex32 secret.
For each share, a valid checksum must be generated in accordance with the
Checksum section.

The codex32 secret and the ''t''-1 codex32 shares form a set of ''t'' valid
codex32 strings from which additional shares can be derived as described
above.

====For a fresh master seed====

In the case that the user wishes to generate a fresh master seed, the user
chooses a threshold value ''t'' and an identifier, then generates ''t''
random codex32 shares, using the generation procedure from the previous
section.
As before, each share must have the same threshold value ''t'', the same
identifier, and a distinct share index.

With this set of ''t'' codex32 shares, new shares can be derived as
discussed above. This process generates a fresh master seed, whose value
can be retrieved by running the recovery process on any ''t'' of these
shares.

===Long codex32 Strings===

The 13 character checksum design only supports up to 80 data characters.
Excluding the threshold, identifier and index characters, this limits the
payload to 74 characters or 46 bytes.
While this is enough to support the 32-byte advised size of BIP-0032 master
seeds, BIP-0032 allows seeds to be up to 64 bytes in size.
We define a long codex32 string format to support these longer seeds by
defining an alternative checksum.

<source lang="python">
MS32_LONG_CONST = 0x43381e570bf4798ab26

def ms32_long_polymod(values):
GEN = [
0x3d59d273535ea62d897,
0x7a9becb6361c6c51507,
0x543f9b7e6c38d8a2a0e,
0x0c577eaeccf1990d13c,
0x1887f74f8dc71b10651,
]
residue = 0x23181b3
for v in values:
b = (residue >> 70)
residue = (residue & 0x3fffffffffffffffff) << 5 ^ v
for i in range(5):
residue ^= GEN[i] if ((b >> i) & 1) else 0
return residue

def ms32_verify_long_checksum(data):
return ms32_long_polymod(data) == MS32_LONG_CONST

def ms32_create_long_checksum(data):
values = data
polymod = ms32_long_polymod(values + [0] * 15) ^ MS32_LONG_CONST
return [(polymod >> 5 * (14 - i)) & 31 for i in range(15)]
</source>

A long codex32 string follows the same specification as a regular codex32
string with the following changes.

* The payload is a sequence of between 75 and 103 Bech32 characters.
* The checksum consists of 15 Bech32 characters as defined above.

A codex32 string with a data part of 94 or 95 characters is never legal as
a regular codex32 string is limited to 93 data characters and a long
codex32 string is at least 96 characters.

Generation of long shares and recovery of the master seed from long shares
proceeds in exactly the same way as for regular shares with the
<code>ms32_interpolate</code> function.

The long checksum is designed to be an error correcting code that can
correct up to 4 character substitutions, up to 8 unreadable characters
(called erasures), or up to 15 consecutive erasures.
As with regular checksums we do not specify how an implementation should
implement error correction, and all our recommendations for error
correction of regular codex32 strings also apply to long codex32 strings.

==Rationale==

This scheme is based on the observation that the Lagrange interpolation of
valid codewords in a BCH code will always be a valid codeword.
This means that derived shares will always have valid checksum, and a
sufficient threshold of shares with valid checksums will derive a secret
with a valid checksum.

The header system is also compatible with Lagrange interpolation, meaning
all derived shares will have the same identifier and will have the
appropriate share index.
This fact allows the header data to be covered by the checksum.

The checksum size and identifier size have been chosen so that the encoding
of 128-bit seeds and shares fit within 48 characters.
This is a standard size for many common seed storage formats, which has
been popularized by the 12 four-letter word format of the BIP-0039 mnemonic.

The 13 character checksum is adequate to correct 4 errors in up to 93
characters (80 characters of data and 13 characters of the checksum). This
is somewhat better quality than the checksum used in SLIP-0039.

For 256-bit seeds and shares our strings are 74 characters, which fits into
the 96 character format of the 24 four-letter word format of the BIP-0039
mnemonic, with plenty of room to spare.

A longer checksum is needed to support up to 512-bit seeds, the longest
seed length specified in BIP-0032, as the 13 character checksum isn't
adequate for more than 80 data characters.
While we could use the 15 character checksum for both cases, we prefer to
keep the strings as short as possible for the more common cases of 128-bit
and 256-bit master seeds.
We only guarantee to correct 4 characters no matter how long the string is.
Longer strings mean more chances for transcription errors, so shorter
strings are better.

The longest data part using the regular 13 character checksum is 93
characters and corresponds to a 400-bit secret.
At this length, the prefix <code>MS1</code> is not covered by the checksum.
This is acceptable because the checksum scheme itself requires you to know
that the <code>MS1</code> prefix is being used in the first place.
If the prefix is damaged and a user is guessing that the data might be
using this scheme, then the user can enter the available data explicitly
using the suspected <code>MS1</code> prefix.

==Backwards Compatibility==

codex32 is an alternative to BIP-0039 and SLIP-0039.
It is technically possible to derive the BIP32 master seed from seed words
encoded in one of these schemes, and then to encode this seed in codex32.
For BIP-0039 this process is irreversible, since it involves hashing the
original words.
Furthermore, the resulting seed will be 512 bits long, which may be too
large to be safely and conveniently handled.

SLIP-0039 seed words can be reversibly converted to master seeds, so it is
possible to interconvert between SLIP-0039 and codex32.
However, SLIP-0039 '''shares''' cannot be converted to codex32 shares
because the two schemes use a different underlying field.

The authors of this BIP do not recommend interconversion.
Instead, users who wish to switch to codex32 should generate a fresh seed
and sweep their coins.

==Reference Implementation==

* [https://secretcodex32.com/docs/2023-02-14--bw.ps Reference PostScript
Implementation]
* FIXME add Python implementation
* FIXME add Rust implementation

==Test Vectors==

===Test vector 1===

This example shows the codex32 format, when used without splitting the
secret into any shares.
The data part contains 26 Bech32 characters, which corresponds to 130 bits.
We truncate the last two bits in order to obtain a 128-bit master seed.

codex32 secret (Bech32):
<code>ms10testsxxxxxxxxxxxxxxxxxxxxxxxxxx4nzvca9cmczlw</code>

Master secret (hex): <code>318c6318c6318c6318c6318c6318c631</code>

* human-readable part: <code>ms</code>
* separator: <code>1</code>
* k value: <code>0</code> (no secret splitting)
* identifier: <code>test</code>
* share index: <code>s</code> (the secret)
* data: <code>xxxxxxxxxxxxxxxxxxxxxxxxxx</code>
* checksum: <code>4nzvca9cmczlw</code>

===Test vector 2===

This example shows generating a new master seed using "random" codex32
shares, as well as deriving an additional codex32 share, using ''k''=2 and
an identifier of <code>NAME</code>.
Although codex32 strings are canonically all lowercase, it's also valid to
use all uppercase.

Share with index <code>A</code>:
<code>MS12NAMEA320ZYXWVUTSRQPNMLKJHGFEDCAXRPP870HKKQRM</code>

Share with index <code>C</code>:
<code>MS12NAMECACDEFGHJKLMNPQRSTUVWXYZ023FTR2GDZMPY6PN</code>

* Derived share with index <code>D</code>:
<code>MS12NAMEDLL4F8JLH4E5VDVULDLFXU2JHDNLSM97XVENRXEG</code>
* Secret share with index <code>S</code>:
<code>MS12NAMES6XQGUZTTXKEQNJSJZV4JV3NZ5K3KWGSPHUH6EVW</code>
* Master secret (hex): <code>d1808e096b35b209ca12132b264662a5</code>

Note that per BIP-0173, the lowercase form is used when determining a
character's value for checksum purposes.
In particular, given an all uppercase codex32 string, we still use
lowercase <code>ms</code> as the human-readable part during checksum
construction.

===Test vector 3===

This example shows splitting an existing 128-bit master seed into "random"
codex32 shares, using ''k''=3 and an identifier of <code>cash</code>.
We appended two zero bits in order to obtain 26 Bech32 characters (130 bits
of data) from the 128-bit master seed.

Master secret (hex): <code>ffeeddccbbaa99887766554433221100</code>

Secret share with index <code>s</code>:
<code>ms13cashsllhdmn9m42vcsamx24zrxgs3qqjzqud4m0d6nln</code>

Share with index <code>a</code>:
<code>ms13casha320zyxwvutsrqpnmlkjhgfedca2a8d0zehn8a0t</code>

Share with index <code>c</code>:
<code>ms13cashcacdefghjklmnpqrstuvwxyz023949xq35my48dr</code>

* Derived share with index <code>d</code>:
<code>ms13cashd0wsedstcdcts64cd7wvy4m90lm28w4ffupqs7rm</code>
* Derived share with index <code>e</code>:
<code>ms13casheekgpemxzshcrmqhaydlp6yhms3ws7320xyxsar9</code>
* Derived share with index <code>f</code>:
<code>ms13cashf8jh6sdrkpyrsp5ut94pj8ktehhw2hfvyrj48704</code>

Any three of the five shares among <code>acdef</code> can be used to
recover the secret.

Note that the choice to append two zero bits was arbitrary, and any of the
following four secret shares would have been valid choices.
However, each choice would have resulted in a different set of derived
shares.

* <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qqjzqud4m0d6nln</code>
* <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qpte35dvzkjpt0r</code>
* <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qzfatvdwq5692k6</code>
* <code>ms13cashsllhdmn9m42vcsamx24zrxgs3qrsx6ydhed97jx2</code>

===Test vector 4===

This example shows converting a 256-bit secret into a codex32 secret,
without splitting the secret into any shares.
We appended four zero bits in order to obtain 52 Bech32 characters (260
bits of data) from the 256-bit secret.

256-bit secret (hex):
<code>ffeeddccbbaa99887766554433221100ffeeddccbbaa99887766554433221100</code>

* codex32 secret:
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqqtum9pgv99ycma</code>

Note that the choice to append four zero bits was arbitrary, and any of the
following sixteen codex32 secrets would have been valid:

*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqqtum9pgv99ycma</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqpj82dp34u6lqtd</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqzsrs4pnh7jmpj5</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqrfcpap2w8dqezy</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqy5tdvphn6znrf0</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq9dsuypw2ragmel</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqx05xupvgp4v6qx</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq8k0h5p43c2hzsk</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqgum7hplmjtr8ks</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqf9q0lpxzt5clxq</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq28y48pyqfuu7le</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqt7ly0paesr8x0f</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqvrvg7pqydv5uyz</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqd6hekpea5n0y5j</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyqwcnrwpmlkmt9dt</code>
*
<code>ms10leetsllhdmn9m42vcsamx24zrxgs3qrl7ahwvhw4fnzrhve25gvezzyq0pgjxpzx0ysaam</code>

===Test vector 5===

This example shows generating a new 512-bit master seed using "random"
codex32 characters and appending a checksum.
The payload contains 103 Bech32 characters, which corresponds to 515 bits.
The last three bits are discarded when converting to a 512-bit master seed.

This is an example of a '''Long codex32 String'''.

* Secret share with index <code>S</code>:
<code>MS100C8VSM32ZXFGUHPCHTLUPZRY9X8GF2TVDW0S3JN54KHCE6MUA7LQPZYGSFJD6AN074RXVCEMLH8WU3TK925ACDEFGHJKLMNPQRSTUVWXY06FHPV80UNDVARHRAK</code>
* Master secret (hex):
<code>dc5423251cb87175ff8110c8531d0952d8d73e1194e95b5f19d6f9df7c01111104c9baecdfea8cccc677fb9ddc8aec5553b86e528bcadfdcc201c17c638c47e9</code>

==Appendix==

===Mathematical Companion===

Below we use the Bech32 character set to denote values in GF[32].
In Bech32, the letter <code>Q</code> denotes zero and the letter
<code>P</code> denotes one.
The digits <code>0</code> and <code>2</code> through <code>9</code> do
''not'' denote their numeric values.
They are simply elements of GF[32].

The generating polynomial for our BCH code is as follows.

We extend GF[32] to GF[1024] by adjoining a primitive cube root of unity,
<code>ζ</code>, satisfying <code>ζ^2 = ζ + P</code>.

We select <code>β := G ζ</code> which has order 93, and construct the
product <code>(x - β^i)</code> for <code>i</code> in <code>{17, 20, 46, 49,
52, 77, 78, 79, 80, 81, 82, 83, 84}</code>.
The resulting polynomial is our generating polynomial for our 13 character
checksum:

x^13 + E x^12 + M x^11 + 3 x^10 + G x^9 + Q x^8 + E x^7 + E x^6 + E x^5
+ L x^4 + M x^3 + C x^2 + S x + S

For our long checksum, we select <code>γ := E + X ζ</code>, which has order
1023, and construct the product <code>(x - γ^i)</code> for <code>i</code>
in <code>{32, 64, 96, 895, 927, 959, 991, 1019, 1020, 1021, 1022, 1023,
1024, 1025, 1026}</code>.
The resulting polynomial is our generating polynomial for our 15 character
checksum for long strings:

x^15 + 0 x^14 + 2 x^13 + E x^12 + 6 x^11 + F x^10 + E x^9 + 4 x^8 + X
x^7 + H x^6 + 4 x^5 + X x^4 + 9 x^3 + K x^2 + Y x^1 + H

(Reminder: the character <code>0</code> does ''not'' denote the zero of the
field.)

-----END BIP-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230215/4ef5f4ec/attachment-0001.html>;

📅 Original date posted:2023-02-18 🗒️ Summary of this ...

2023-06-07T23:19:36Z

In reply to nevent1q…faxs
_________________________

📅 Original date posted:2023-02-18
🗒️ Summary of this message: A developer working on the Simplicity language, which prunes unused case branches, explains that it cannot prevent agents from posting unused data blobs as part of their programs.
📝 Original message:On Sat, Feb 18, 2023 at 5:11 AM vjudeu via bitcoin-dev <
bitcoin-dev at 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 *<some data blob>*; unit which is
roughly equivalent PUSH *<data blob>* 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230218/2db79aa2/attachment.html>;

📅 Original date posted:2023-02-11 🗒️ Summary of this ...

2023-06-07T23:19:29Z

In reply to nevent1q…7gx4
_________________________

📅 Original date posted:2023-02-11
🗒️ Summary of this message: A bug in Taproot allows the same Tapleaf to be repeated, but signing the entire tapbranch instead of the tapleaf can fix it.
📝 Original message: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 <aj at erisian.com.au> wrote:

> On 9 February 2023 12:04:16 am AEST, Russell O'Connor via bitcoin-dev <
> bitcoin-dev at 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, <
> michaelfolkson at 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 at 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 at lists.linuxfoundation.org> wrote:
> >>
> >>>
> >>> Some people highlighted some minor problems with my last email:
> >>>
> >>> On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via
> bitcoin-dev
> >>> wrote:
> >>> >
> >>> > <snip>
> >>> >
> >>> > [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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230211/40833a03/attachment.html>;

📅 Original date posted:2023-02-08 🗒️ Summary of this ...

2023-06-07T23:19:28Z

In reply to nevent1q…lcs3
_________________________

📅 Original date posted:2023-02-08
🗒️ Summary of this message: Bug in Taproot allows repeated Tapleaf at different Taplevels, fixed by signing entire Tapbranch instead of Tapleaf.
📝 Original message:The fix for the bug is to sign the entire tapbranch instead of the tapleaf.

On Wed., Feb. 8, 2023, 04:35 Michael Folkson, <michaelfolkson at 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 at 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 at lists.linuxfoundation.org> wrote:
>
>>
>> Some people highlighted some minor problems with my last email:
>>
>> On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev
>> wrote:
>> >
>> > <snip>
>> >
>> > [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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230208/d4adc425/attachment-0001.html>;

📅 Original date posted:2023-02-07 🗒️ Summary of this ...

2023-06-07T23:19:27Z

In reply to nevent1q…p5ju
_________________________

📅 Original date posted:2023-02-07
🗒️ Summary of this message: A bug in Taproot allows the same Tapleaf to be repeated multiple times, incurring different Tapfee rates. Always know the entire Taptree when interacting with someone's Tapspend.
📝 Original message: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 at lists.linuxfoundation.org> wrote:

>
> Some people highlighted some minor problems with my last email:
>
> On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev
> wrote:
> >
> > <snip>
> >
> > [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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230207/57930553/attachment.html>;

📅 Original date posted:2023-02-05 🗒️ Summary of this ...

2023-06-07T23:19:02Z

In reply to nevent1q…mh5m
_________________________

📅 Original date posted:2023-02-05
🗒️ Summary of this message: A discussion on the use of witness data versus script pubkey in Bitcoin transactions, with a suggestion to let users decide how to use OpReturn.
📝 Original message:On Sat., Feb. 4, 2023, 21:01 Peter Todd, <pete at petertodd.org> wrote:

>
>
> On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> 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.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230205/bfa453c8/attachment-0001.html>;

📅 Original date posted:2023-02-04 🗒️ Summary of this ...

2023-06-07T23:19:01Z

In reply to nevent1q…stet
_________________________

📅 Original date posted:2023-02-04
🗒️ Summary of this message: Using witness data can be cheaper than script pubkey for data size beyond a certain point, which could be the basis for a reasonable OP_RETURN proposal.
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/248ec360/attachment.html>;

📅 Original date posted:2022-11-04 📝 Original message:On ...

2023-06-07T23:16:35Z

In reply to nevent1q…2upj
_________________________

📅 Original date posted:2022-11-04
📝 Original message:On Fri, Nov 4, 2022 at 4:04 PM Trey Del Bonis via bitcoin-dev <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221104/8ff770cd/attachment.html>;

📅 Original date posted:2022-10-17 📝 Original ...

2023-06-07T23:15:19Z

In reply to nevent1q…0yll
_________________________

📅 Original date posted:2022-10-17
📝 Original message:>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 at 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 seems that the NoRBF crowd want to rely on an honest majority
> assumption where the honest behavior is not doing replacement if not
> requested. This is really not much different than trying to close lightning
> channels "the right way".
>
> However, where it may be different, is that even in the presence of honest
> majority, the safety of 0conf isn't assured given the potential of race
> conditions in the mempool. Therefore it's not clear to me that 0conf
> working well is something you can drive from the Honest Majority Assumption
> (where honest includes first seen).
>
>
> Overall, it might be nice to more tightly document what bitcoins
> assumptions are in practice and what those assumptions do in terms of
> properties of Bitcoin, as well as pathways to weakening the assumptions
> without compromising the behaviors users expect the network to have. An
> "extended white paper" if you will.
>
>
> It's somewhat clear to me that we shouldn't weaken assumptions that only
> seem local to one subsystem of Bitcoin if they end up destabilizing another
> system. In particular, things that decrease "transaction utility" for end
> users decrease the demand for transactions which hurts the fee market's
> longer term viability, even if we feel good about making an honest policy
> assumption into a self interested policy assumption.
>
> A last reflection is that Bitcoin is specified with an honest majority
> assumption, but also has a rational dishonest minority assumption over both
> endogenous (rewards) and exogenous (electricity) costs. Satoshi did not
> suggest, at least as I read it, that Bitcoin works with an rational
> majority assumption. (If anyone thinks these three are similar properties
> you can make some trivial counterexamples)
>
>
> Cheers,
>
> Jeremy
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221017/cf650127/attachment-0001.html>;

📅 Original date posted:2022-10-18 📝 Original message:On ...

2023-06-07T23:15:15Z

In reply to nevent1q…ydeq
_________________________

📅 Original date posted:2022-10-18
📝 Original message:On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev at 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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221018/e2142e1a/attachment-0001.html>;

📅 Original date posted:2022-07-11 📝 Original message:Oops, ...

2023-06-07T23:11:42Z

In reply to nevent1q…khvt
_________________________

📅 Original date posted:2022-07-11
📝 Original message: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 <pete at petertodd.org> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220711/2b9c824a/attachment.html>;

📅 Original date posted:2022-07-11 📝 Original message:On ...

2023-06-07T23:11:41Z

In reply to nevent1q…dcga
_________________________

📅 Original date posted:2022-07-11
📝 Original message:On Mon, Jul 11, 2022 at 2:19 PM Bram Cohen via bitcoin-dev <
bitcoin-dev at 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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220711/6e8e216d/attachment-0001.html>;

📅 Original date posted:2022-05-11 📝 Original message:Hi ...

2023-06-07T23:09:33Z

In reply to nevent1q…mlz0
_________________________

📅 Original date posted:2022-05-11
📝 Original message: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 at 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/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1
>
> State transitions diagram:
>
> 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 <https://protonmail.com/>; secure email.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220511/2cdd2915/attachment.html>;

📅 Original date posted:2022-05-13 📝 Original message:On ...

2023-06-07T23:09:22Z

In reply to nevent1q…ande
_________________________

📅 Original date posted:2022-05-13
📝 Original message:On Fri, May 13, 2022 at 5:43 PM Anthony Towns <aj at erisian.com.au> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220513/e19a4b5f/attachment.html>;

📅 Original date posted:2022-05-12 📝 Original message:On ...

2023-06-07T23:09:21Z

In reply to nevent1q…zgua
_________________________

📅 Original date posted:2022-05-12
📝 Original message:On Wed, May 11, 2022 at 11:07 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Russell,
>
> > On Wed, May 11, 2022 at 7:42 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220512/af1e5596/attachment-0001.html>;

📅 Original date posted:2022-05-11 📝 Original message:On ...

2023-06-07T23:09:20Z

In reply to nevent1q…f2s4
_________________________

📅 Original date posted:2022-05-11
📝 Original message:On Wed, May 11, 2022 at 7:42 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220511/50e8333f/attachment-0001.html>;

📅 Original date posted:2022-05-06 📝 Original message:On ...

2023-06-07T23:08:41Z

In reply to nevent1q…3szh
_________________________

📅 Original date posted:2022-05-06
📝 Original message:On Fri, May 6, 2022 at 2:01 PM Jorge Timón via bitcoin-dev <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220506/7b1fba52/attachment.html>;

📅 Original date posted:2022-04-25 📝 Original message:On ...

2023-06-07T23:07:46Z

In reply to nevent1q…vrgk
_________________________

📅 Original date posted:2022-04-25
📝 Original message:On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud <billy.tetrud at gmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220425/99e1a76f/attachment.html>;

📅 Original date posted:2022-04-23 📝 Original message:Okay, ...

2023-06-07T23:07:44Z

In reply to nevent1q…gjsf
_________________________

📅 Original date posted:2022-04-23
📝 Original message: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 <lf-lists at mattcorallo.com>
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 :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220423/8077c9f2/attachment-0001.html>;

📅 Original date posted:2022-04-23 📝 Original message:On ...

2023-06-07T23:07:44Z

In reply to nevent1q…we2h
_________________________

📅 Original date posted:2022-04-23
📝 Original message:On Sat, Apr 23, 2022 at 12:56 AM Billy Tetrud <billy.tetrud at gmail.com>
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
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults>;. 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220423/4e7b865d/attachment.html>;

📅 Original date posted:2022-04-22 📝 Original message:On ...

2023-06-07T23:07:43Z

In reply to nevent1q…6trn
_________________________

📅 Original date posted:2022-04-22
📝 Original message:On Fri, Apr 22, 2022 at 12:29 PM James O'Beirne via bitcoin-dev <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220422/a55ab1e9/attachment.html>;

📅 Original date posted:2022-04-21 📝 Original message:On ...

2023-06-07T23:07:28Z

In reply to nevent1q…vd34
_________________________

📅 Original date posted:2022-04-21
📝 Original message:On Thu, Apr 21, 2022 at 1:04 AM Anthony Towns via bitcoin-dev <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220421/7dabd75a/attachment-0001.html>;

📅 Original date posted:2022-03-22 📝 Original message:Thanks ...

2023-06-07T23:06:34Z

In reply to nevent1q…lzvw
_________________________

📅 Original date posted:2022-03-22
📝 Original message: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 <ZmnSCPxj at protonmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220322/4fd9e0be/attachment.html>;

📅 Original date posted:2022-03-22 📝 Original ...

2023-06-07T23:06:32Z

In reply to nevent1q…vaua
_________________________

📅 Original date posted:2022-03-22
📝 Original message: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 at 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 register banks which could be
> used very generically and interchangeably.
> Instructions had the same size and every instruction took a
> fixed number of cycles.
>
> In CISC you usually had shorter code which could be written
> by human programmers in assembly language or machine language.
> In RISC, you generally had longer code, often difficult for
> human programmers to write, and you *needed* a compiler to
> generate it (unless you were very careful, or insane enough
> you could scroll over multiple pages of instructions without
> becoming more insane), or else you might forget about stuff
> like jump slots.
>
> For the most part, RISC lost, since most modern processors
> today are x86 or x86-64, an instruction set with varying
> instruction sizes, varying number of cycles per instruction,
> and complex instructions with application-specific uses.
>
> Or at least, it *looks like* RISC lost.
> In the 90s, Intel was struggling since their big beefy CISC
> designs were becoming too complicated.
> Bugs got past testing and into mass-produced silicon.
> RISC processors were beating the pants off 386s in terms of
> raw number of computations per second.
>
> RISC processors had the major advantage that they were
> inherently simpler, due to having fewer specific circuits
> and filling up their silicon with general-purpose registers
> (which are large but very simple circuits) to compensate.
> This meant that processor designers could fit more of the
> design in their merely human meat brains, and were less
> likely to make mistakes.
> The fixed number of cycles per instruction made it trivial
> to create a fixed-length pipeline for instruction processing,
> and practical RISC processors could deliver one instruction
> per clock cycle.
> Worse, the simplicity of RISC meant that smaller and less
> experienced teams could produce viable competitors to the
> Intel x86s.
>
> So what Intel did was to use a RISC processor, and add a
> special Instruction Decoder unit.
> The Instruction Decoder would take the CISC instruction
> stream accepted by classic Intel x86 processors, and emit
> RISC instructions for the internal RISC processor.
> CISC instructions might be variable length and have variable
> number of cycles, but the emitted RISC instructions were
> individually fixed length and fixed number of cycles.
> A CISC instruction might be equivalent to a single RISC
> instruction, or several.
>
> With this technique, Intel could deliver performance
> approaching their RISC-only competition, while retaining
> back-compatibility with existing software written for their
> classic CISC processors.
>
> At its core, the Instruction Decoder was a table-driven
> parser.
> This lookup table could be stored into on-chip flash memory.
> This had the advantage that the on-chip flash memory could be
> updated in case of bugs in the implementation of CISC
> instructions.
> This on-chip flash memory was then termed "microcode".
>
> Important advantages of this "microcode" technique were:
>
> * Back-compatibility with existing instruction sets.
> * Easier and more scalable underlying design due to ability
> to use RISC techniques while still supporting CISC instruction
> sets.
> * Possible to fix bugs in implementations of complex CISC
> instructions by uploading new microcode.
>
> (Obviously I have elided a bunch of stuff, but the above
> rough sketch should be sufficient as introduction.)
>
> Bitcoin Consensus Layer As Hardware
> -----------------------------------
>
> While Bitcoin fullnode implementations are software, because
> of the need for consensus, this software is not actually very
> "soft".
> One can consider that, just as it would take a long time for
> new hardware to be designed with a changed instruction set,
> it is similarly taking a long time to change Bitcoin to
> support changed feature sets.
>
> Thus, we should really consider the Bitcoin consensus layer,
> and its SCRIPT, as hardware that other Bitcoin software and
> layers run on top of.
>
> This thus opens up the thought of using techniques that were
> useful in hardware design.
> Such as microcode: a translation layer from "old" instruction
> sets to "new" instruction sets, with the ability to modify this
> mapping.
>
> Microcode For Bitcoin SCRIPT
> ============================
>
> I propose:
>
> * Define a generic, low-level language (the "RISC language").
> * Define a mapping from a specific, high-level language to
> the above language (the microcode).
> * Allow users to sacrifice Bitcoins to define a new microcode.
> * Have users indicate the microcode they wish to use to
> interpret their Tapscripts.
>
> As a concrete example, let us consider the current Bitcoin
> SCRIPT as the "CISC" language.
>
> We can then support a "RISC" language that is composed of
> general instructions, such as arithmetic, SECP256K1 scalar
> and point math, bytevector concatenation, sha256 midstates,
> bytevector bit manipulation, transaction introspection, and
> so on.
> This "RISC" language would also be stack-based.
> As the "RISC" language would have more possible opcodes,
> we may need to use 2-byte opcodes for the "RISC" language
> instead of 1-byte opcodes.
> Let us call this "RISC" language the micro-opcode language.
>
> Then, the "microcode" simply maps the existing Bitcoin
> SCRIPT `OP_` codes to one or more `UOP_` micro-opcodes.
>
> An interesting fact is that stack-based languages have
> automatic referential transparency; that is, if I define
> some new word in a stack-based language and use that word,
> I can replace verbatim the text of the new word in that
> place without issue.
> Compare this to a language like C, where macro authors
> have to be very careful about inadvertent variable
> capture, wrapping `do { ... } while(0)` to avoid problems
> with `if` and multiple statements, multiple execution, and
> so on.
>
> Thus, a sequence of `OP_` opcodes can be mapped to a
> sequence of equivalent `UOP_` micro-opcodes without
> changing the interpretation of the source language, an
> important property when considering such a "compiled"
> language.
>
> We start with a default microcode which is equivalent
> to the current Bitcoin language.
> When users want to define a new microcode to implement
> new `OP_` codes or change existing `OP_` codes, they
> can refer to a "base" microcode, and only have to
> provide the new mappings.
>
> A microcode is fundamentally just a mapping from an
> `OP_` code to a variable-length sequence of `UOP_`
> micro-opcodes.
>
> ```Haskell
> import Data.Map
> -- type Opcode
> -- type UOpcode
> newtype Microcode = Microcode (Map.Map Opcode [UOpcode])
> ```
>
> Semantically, the SCRIPT interpreter processes `UOP_`
> micro-opcodes.
>
> ```Haskell
> -- instance Monad Interpreter -- can `fail`.
> interpreter :: Transaction -> TxInput -> [UOpcode] -> Interpreter ()
> ```
>
> Example
> -------
>
> Suppose a user wants to re-enable `OP_CAT`, and nothing
> else.
>
> That user creates a microcode, referring to the current
> default Bitcoin SCRIPT microcode as the "base".
> The base microcode defines `OP_CAT` as equal to the
> sequence `UOP_FAIL` i.e. a micro-opcode that always fails.
> However, the new microcode will instead redefine the
> `OP_CAT` as the micro-opcode sequence `UOP_CAT`.
>
> Microcodes then have a standard way of being represented
> as a byte sequence.
> The user serializes their new microcode as a byte
> sequence.
>
> Then, the user creates a new transaction where one of
> the outputs contains, say, 1.0 Bitcoins (exact required
> value TBD), and has the `scriptPubKey` of
> `OP_TRUE OP_RETURN <serialized_microcode>`.
> This output is a "microcode introduction output", which
> is provably unspendable, thus burning the Bitcoins.
>
> (It need not be a single user, multiple users can
> coordinate by signing a single transaction that commits
> their funds to the microcode introduction.)
>
> Once the above transaction has been deeply confirmed,
> the user can then take the hash of the microcode
> serialization.
> Then the user can use a SCRIPT with `OP_CAT` enabled,
> by using a Tapscript with, say, version `0xce`, and
> with the SCRIPT having the microcode hash as its first
> bytes, followed by the `OP_` codes.
>
> Fullnodes will then process recognized microcode
> introduction outputs and store mappings from their
> hashes to the microcodes in a new microcodes index.
> Fullnodes can then process version-`0xce` Tapscripts
> by checking if the microcodes index has the indicated
> microcode hash.
>
> Semantically, fullnodes take the SCRIPT, and for each
> `OP_` code in it, expands it to a sequence of `UOP_`
> micro-opcodes, then concatenates each such sequence.
> Then, the SCRIPT interpreter operates over a sequence
> of `UOP_` micro-opcodes.
>
> Optimizing Microcodes
> ---------------------
>
> Suppose there is some new microcode that users have
> published onchain.
>
> We want to be able to execute the defined microcode
> faster than expanding an `OP_`-code SCRIPT to a
> `UOP_`-code SCRIPT and having an interpreter loop
> over the `UOP_`-code SCRIPT.
>
> We can use LLVM.
>
> WARNING: LLVM might not be appropriate for
> network-facing security-sensitive applications.
> In particular, LLVM bugs. especially nondeterminism
> bugs, can lead to consensus divergence and disastrous
> chainsplits!
> On the other hand, LLVM bugs are compiler bugs and
> the same bugs can hit the static compiler `cc`, too,
> since the same LLVM code runs in both JIT and static
> compilation, so this risk already exists for Bitcoin.
> (i.e. we already rely on LLVM not being buggy enough
> to trigger Bitcoin consensus divergence, else we would
> have written Bitcoin Core SCRIPT interpreter in
> assembly.)
>
> Each `UOP_`-code has an equivalent tree of LLVM code.
> For each `Opcode` in the microcode, we take its
> sequence of `UOpcode`s and expand them to this tree,
> concatenating the equivalent trees for each `UOpcode`
> in the sequence.
> Then we ask LLVM to JIT-compile this code to a new
> function, running LLVM-provided optimizers.
> Then we put a pointer to this compiled function to a
> 256-long array of functions, where the array index is
> the `OP_` code.
>
> The SCRIPT interpreter then simply iterates over the
> `OP_` code SCRIPT and calls each of the JIT-compiled
> functions.
> This reduces much of the overhead of the `UOP_` layer
> and makes it approach the current performance of the
> existing `OP_` interpreter.
>
> For the default Bitcoin SCRIPT, the opcodes array
> contains pointers to statically-compiled functions.
> A microcode that is based on the default Bitcoin
> SCRIPT copies this opcodes array, then overwrites
> the entries.
>
> Future versions of Bitcoin Core can "bless"
> particular microcodes by providing statically-compiled
> functions for those microcodes.
> This leads to even better performance (there is
> no need to recompile ancient onchain microcodes each
> time Bitcoin Core starts) without any consensus
> divergence.
> It is a pure optimization and does not imply a
> tightening of rules, and is thus not a softfork.
>
> (To reduce the chance of network faults being used
> to poke into `W|X` memory (since `W|X` memory is
> needed in order to actually JIT compile) we can
> isolate the SCRIPT interpreter into its own process
> separate from the network-facing code.
> This does imply additional overhead in serializing
> transactions we want to ask the SCRIPT interpreter
> to validate.)
>
> Comparison To Jets
> ------------------
>
> This technique allows users to define "jets", i.e.
> sequences of low-level general operations that users
> have determined are common enough they should just
> be implemented as faster code that is executed
> directly by the underlying hardware processor rather
> than via a software interpreter.
> Basically, each redefined `OP_` code is a jet of a
> sequence of `UOP_` micro-opcodes.
>
> We implement this by dynamically JIT-compiling the
> proposed jets, as described above.
> SCRIPTs using jetted code remain smaller, as the
> jet definition is done in a previous transaction and
> does not require copy-pasta (Do Not Repeat Yourself!).
> At the same time, jettification is not tied to
> developers, thus removing the need to keep softforking
> new features --- we only need define a sufficiently
> general language and then we can implement pretty much
> anything worth implementing (and a bunch of other things
> that should not be implemented, but hey, users gonna
> use...).
>
> Bugs in existing microcodes can be fixed by basing a
> new microcode from the existing microcode, and
> redefining the buggy implementation.
> Existing Tapscripts need to be re-spent to point to
> the new bugfixed microcode, but if you used the
> point-spend branch as an N-of-N of all participants
> you have an upgrade mechanism for free.
>
> In order to ensure that the JIT-compilation of new
> microcodes is not triggered trivially, we require
> that users petitioning for the jettification of some
> operations (i.e. introducing a new microcode) must
> sacrifice Bitcoins.
>
> Burning Bitcoins is better than increasing the weight
> of microcode introduction outputs; all fullnodes are
> affected by the need to JIT-compile the new microcode,
> so they benefit from the reduction in supply, thus
> getting compensated for the work of JIT-compiling the
> new microcode.
> Ohter mechanisms for making microcode introduction
> outputs expensive are also possible.
>
> Nothing really requires that we use a stack-based
> language for this; any sufficiently FP language
> should allow referential transparency.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220322/402ad6eb/attachment-0001.html>;

📅 Original date posted:2022-03-12 📝 Original message:On ...

2023-06-07T23:06:03Z

In reply to nevent1q…2v4p
_________________________

📅 Original date posted:2022-03-12
📝 Original message:On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón <jtimon at jtimon.cc> 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
<https://b10c.me/blog/007-spending-p2tr-pre-activation/>; 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220312/11e3c7a0/attachment.html>;

📅 Original date posted:2022-03-11 📝 Original message:On ...

2023-06-07T23:06:02Z

In reply to nevent1q…2ufj
_________________________

📅 Original date posted:2022-03-11
📝 Original message:On Fri, Mar 11, 2022 at 7:18 AM Jorge Timón <jtimon at jtimon.cc> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220311/40b6c9ad/attachment-0001.html>;

📅 Original date posted:2022-03-10 📝 Original message:On ...

2023-06-07T23:06:00Z

In reply to nevent1q…3t4f
_________________________

📅 Original date posted:2022-03-10
📝 Original message:On Thu., Mar. 10, 2022, 08:04 Jorge Timón via bitcoin-dev, <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220310/3b9bd8b8/attachment.html>;

📅 Original date posted:2022-03-05 📝 Original message:On ...

2023-06-07T23:05:14Z

In reply to nevent1q…x0yn
_________________________

📅 Original date posted:2022-03-05
📝 Original message:On Sat, Mar 5, 2022 at 8:41 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220305/d223d490/attachment.html>;

📅 Original date posted:2022-03-06 📝 Original message:The ...

2023-06-07T23:05:14Z

In reply to nevent1q…g6ea
_________________________

📅 Original date posted:2022-03-06
📝 Original message:The circuit generated from Simplicity was larger than the hand made one.

On Sat, Mar 5, 2022 at 6:20 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Russell,
>
> > On Sat, Mar 5, 2022 at 8:41 AM Jeremy Rubin via bitcoin-dev <
> bitcoin-dev at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220305/b803a6b5/attachment.html>;

📅 Original date posted:2022-02-15 📝 Original message:> ...

2023-06-07T23:04:19Z

In reply to nevent1q…460v
_________________________

📅 Original date posted:2022-02-15
📝 Original message:> >> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220215/12596d01/attachment.html>;

📅 Original date posted:2022-02-16 📝 Original message:On ...

2023-06-07T23:03:26Z

In reply to nevent1q…hc0k
_________________________

📅 Original date posted:2022-02-16
📝 Original message:On Tue, Feb 15, 2022 at 10:45 PM Rusty Russell <rusty at rustcorp.com.au>
wrote:

> Jeremy Rubin <jeremy.l.rubin at gmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220215/cf036cf5/attachment.html>;

📅 Original date posted:2022-02-15 📝 Original message:On ...

2023-06-07T23:03:25Z

In reply to nevent1q…5v6r
_________________________

📅 Original date posted:2022-02-15
📝 Original message:On Tue, Feb 15, 2022 at 1:57 PM Jeremy Rubin <jeremy.l.rubin at gmail.com>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220215/13792914/attachment.html>;

📅 Original date posted:2022-02-17 📝 Original message:On ...

2023-06-07T23:03:22Z

In reply to nevent1q…74xz
_________________________

📅 Original date posted:2022-02-17
📝 Original message:On Thu, Feb 17, 2022 at 9:27 AM Anthony Towns <aj at erisian.com.au> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220217/6b08b8c5/attachment.html>;

📅 Original date posted:2022-02-08 📝 Original message:On ...

2023-06-07T23:03:20Z

In reply to nevent1q…agu0
_________________________

📅 Original date posted:2022-02-08
📝 Original message:On Mon, Jan 31, 2022 at 8:16 PM Anthony Towns <aj at erisian.com.au> 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 applications; it was a list of
values that CSFSV composes with. Applications include delegation of pubkeys
and oracles, and, in the presence of CAT and transaction reflection
primitives, presumably many more things.

> I guess I'd still be interested in the answer to:
>
> > > If we had CTV, POP_SIGDATA, and SIGHASH_NO_TX_DATA_AT_ALL but no
> OP_CAT,
> > > are there any practical use cases that wouldn't be covered that having
> > > TXHASH/CAT/CHECKSIGFROMSTACK instead would allow? Or where those would
> > > be significantly more convenient/efficient?
> > >
> > > (Assume "y x POP_SIGDATA POP_SIGDATA p CHECKSIGVERIFY q CHECKSIG"
> > > commits to a vector [x,y] via p but does not commit to either via q so
> > > that there's some "CAT"-like behaviour available)
>

I don't know if this is the answer you are looking for, but technically
TXHASH + CAT + SHA256 awkwardly gives you limited transaction reflection.
In fact, you might not even need TXHASH, though it certainly helps.

> TXHASH seems to me to be clearly the more flexible opcode compared to
> CTV; but maybe all that flexibility is wasted, and all the real use
> cases actually just want CHECKSIG or CTV? I'd feel much better having
> some idea of what the advantage of being flexible there is...
>

The flexibility of TXHASH is intended to head off the need for future soft
forks. If we had specific applications in mind, we could simply set up the
transaction hash flags to cover all the applications we know about. But it
is the applications that we don't know about that worry me. If we don't
put options in place with this soft-fork proposal, then they will need
their own soft-fork down the line; and the next application after that, and
so on.

If our attitude is to craft our soft-forks as narrowly as possible to limit
them to what only allows for given tasks, then we are going to end up
needing a lot more soft-forks, and that is not a good outcome.

But all that aside, probably the real question is can we simplify CTV's
> transaction message algorithm, if we assume APO is enabled simultaneously?
> If it doesn't get simplified and needs its own hashing algorithm anyway,
> that would be probably be a good reason to keep the separate.
>
> First, since ANYPREVOUT commits to the scriptPubKey, you'd need to use
> ANYPREVOUTANYSCRIPT for CTV-like behaviour.
>
> ANYPRVOUTANYSCRIPT is specced as commiting to:
> nVersion
> nLockTime
> nSequence
> spend_type and annex present
> sha_annex (if present)
> sha_outputs (ALL) or sha_single_output (SINGLE)
> key_version
> codesep_pos
>
> CTV commits to:
> nVersion
> nLockTime
> scriptSig hash "(maybe!)"
> input count
> sequences hash
> output count
> outputs hash
> input index
>
> (CTV thus allows annex malleability, since it neither commits to the
> annex nor forbids inclusion of an annex)
>
> "output count" and "outputs index" would both be covered by sha_outputs
> with ANYPREVOUTANYSCRIPT|ALL.
>
> I think "scriptSig hash" is only covered to avoid txid malleability; but
> just adjusting your protocol to use APO signatures instead of relying on
> the txid of future transactions also solves that problem.
>
> I believe "sequences hash", "input count" and "input index" are all an
> important part of ensuring that if you have two UTXOs distributing 0.42
> BTC to the same set of addresses via CTV, that you can't combine them in a
> single transaction and end up sending losing one of the UTXOs to fees. I
> don't believe there's a way to resolve that with bip 118 alone, however
> that does seem to be a similar problem to the one that SIGHASH_GROUP
> tries to solve.
>

It was my understanding that it is only "input count = 1" that prevents
this issue.

SIGHASH_GROUP [1] would be an alternative to ALL/SINGLE/NONE, with the exact
> group of outputs being committed to determined via the annex.
> ANYPREVOUTANYSCRIPT|GROUP would commit to:
>
> nVersion
> nLockTime
> nSequence
> spend_type and annex present
> sha_annex (if present)
> sha_group_outputs (GROUP)
> key_version
> codesep_pos
>
> So in that case if you have your two inputs:
>
> 0.42 [pays 0.21 to A, 0.10 to B, 0.10 to C]
> 0.42 [pays 0.21 to A, 0.10 to B, 0.10 to C]
>
> then, either:
>
> a) if they're both committed with GROUP and sig_group_count = 3, then
> the outputs must be [0.21 A, 0.10 B, 0.10 C, 0.21 A, 0.10 B, 0.10
> C], and you don't lose funds
>
> b) if they're both committed with GROUP and the first is
> sig_group_count=3 and the second is sig_group_count=0, then the
> outputs can be [0.21 A, 0.10 B, 0.10 C, *anything] -- but in that
> case the second input is already signalling that it's meant to be
> paired with another input to fund the same three outputs, so any
> funds loss is at least intentional
>
> Note that this means txids are very unstable: if a tx is only protected
> by SIGHASH_GROUP commitments then miners/relayers can add outputs, or
> reorganise the groups without making the tx invalid. Beyond requiring
> the signatures to be APO/APOAS-based to deal with that, we'd also need
> to avoid txs getting rbf-pinned by some malicious third party who pulls
> apart the groups and assembles a new tx that's hard to rbf but also
> unlikely to confirm due to having a low feerate.
>
> Note also that not reusing addresses solves this case -- it's only a
> problem when you're paying the same amounts to the same addresses.
>
> Being able to combine additional inputs and outputs at a later date
> (which necessarily changes the txid) is an advantage though: it lets
> you add additional funds and claim change, which allows you to adjust
> to different fee rates.
>
> I don't think the SIGHASH_GROUP approach would work very well without
> access to the annex, ie if you're trying to do CTV encoded either in a
> plain scriptPubKey or via segwit/p2sh.
>
> I think that would give 16 different sighashes, choosing one of four
> options for outputs,
>
> ALL/NONE/SINGLE/GROUP
> -- which outputs are committed to
>
> and one of four options for inputs,
>
> -/ANYONECANPAY/ANYPREVOUT/ANYPREVOUTANYSCRIPT
> -- all inputs committed to, specific input committed to,
> scriptpubkey/tapscript committed to, or just the
> nseq/annex/codesep_pos
>
> vs the ~155,000 sighashes in the TXHASH proposal.
>
> I don't think there's an efficient way of doing SIGHASH_GROUP via tx
> introspection opcodes that doesn't also introduce a quadratic hashing
> risk -- you need to prevent different inputs from re-hashing distinct but
> overlapping sets of outputs, and if your opcodes only allow grabbing one
> output at a time to add to the message being signed you have to do a lot
> of coding if you want to let the signer choose how many outputs to commit
> to; if you provide an opcode that grabs man outputs to hash, it seems
> hard to do that generically in a way that avoids quadratic behaviour.
>
> So I think that suggests two alternative approaches, beyond the
> VERIFY-vs-PUSH semantic:
>
> - have a dedicated sighash type for CTV (either an explicit one for it,
> per bip119, or support thousands of options like the proposal in this
> thread, one of which happens to be about the same as the bip119 idea)
>
> - use ANYPREVOUTANYSCRIPT|GROUP for CTV, which means also implementing
> annex parsing and better RBF behaviour to avoid those txs being
> excessively vulnerable to pinning; with the advantage being that
> txs using "GROUP" sigs can be combined either for batching purposes
> or for adapting to the fee market after the signature has been made,
> and the disadvantage that you can't rely on stable txids when looking
> for CTV spends and have to continue using APO/APOAS when chaining
> signatures on top of unconfirmed CTV outputs
>
> Cheers,
> aj
>
> [0] Here's bitmatrix trying to multiply two numbers together:
>
> https://medium.com/bit-matrix/technical-how-does-bitmatrix-v1-multiply-two-integers-in-the-absence-of-op-mul-a58b7a3794a3
>
> Likewise, doing a point preimage reveal via clever scripting
> pre-taproot never saw an implementation, despite seeming
> theoretically plausible.
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220207/848ec59e/attachment-0001.html>;

📅 Original date posted:2022-01-28 📝 Original message:On ...

2023-06-07T23:02:59Z

In reply to nevent1q…k757
_________________________

📅 Original date posted:2022-01-28
📝 Original message:On Thu, Jan 27, 2022 at 8:34 PM Anthony Towns <aj at erisian.com.au> 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.

> '<anyprevout-pubkey> CHECKSIGVERIFY can be simulated by '<apo_style_flag>
> TXHASH <pubkey> 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 "<APO:P> CHECKSIGVERIFY" with
> "TXHASH <P> 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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220128/beac8333/attachment.html>;

📅 Original date posted:2022-01-29 📝 Original message:The ...

2023-06-07T23:02:57Z

In reply to nevent1q…mtqu
_________________________

📅 Original date posted:2022-01-29
📝 Original message: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 <j at rubin.io> 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.
>
> <Only hash a single input scriptpubkey> txhash <only hash a single output
> scriptpubkey> txhash equalverify
>
> Is that not a recursive covenant? With a little extra work you can also
> control for amounts and stuff.
>
>
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220129/a5d662ba/attachment.html>;

📅 Original date posted:2022-01-29 📝 Original message:On ...

2023-06-07T23:02:57Z

In reply to nevent1q…h8k9
_________________________

📅 Original date posted:2022-01-29
📝 Original message:On Fri, Jan 28, 2022 at 10:14 AM James O'Beirne <james.obeirne at gmail.com>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220129/cefdbd34/attachment.html>;

📅 Original date posted:2022-01-28 📝 Original message:On ...

2023-06-07T23:02:56Z

In reply to nevent1q…r8ym
_________________________

📅 Original date posted:2022-01-28
📝 Original message:On Thu, Jan 27, 2022 at 7:19 PM James O'Beirne <james.obeirne at gmail.com>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220128/a793638a/attachment-0001.html>;

📅 Original date posted:2022-01-27 📝 Original message:I am ...

2023-06-07T23:02:51Z

In reply to nevent1q…x40j
_________________________

📅 Original date posted:2022-01-27
📝 Original message:I am sensitive to technical debt and soft fork processes, and I don't
believe I'm unordinary particular about these issues. Once implemented,
opcodes must be supported and maintained indefinitely. Some opcodes are
easier to maintain than others. These particular opcodes involve caching
of hash computations and, for that reason, I would judge them to be of
moderate complexity.

But more importantly, soft-forks are inherently a risky process, so we
should be getting as much value out of them as we reasonably can. 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.

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

But that argument basically rests the entire value of CTV on the shoulders
of bare CTV. As I understand, the argument for why we want bare CTV,
instead of just letting people use tapscript, involves the finer details of
weight calculations, and I haven't really reviewed that aspect yet. I
think it would need to be pretty compelling to make it worthwhile to add
CTV for that one use case.

Regarding "OP_TXHASH+CSFSV doesn't seem to be the 'full' set of things
needed", I totally agree we will want more things such as CAT, rolling
SHA256 opcodes, wider arithmetic, pushing amounts onto the stack, some kind
of tapleaf manipulation and/or TWEAKVERIFY. For now, I only want to argue
TXHASH+CSFSV is better than CTV+APO because it gives us more value, namely
oracle signature verification. In particular, I want to argue that
TXHASH's push semantics is better that CTV's verify semantics because it
composes better by not needing to carry an extra 32-bytes (per instance) in
the witness data. I expect that in a world of full recursive covenants,
TXHASH would still be useful as a fast and cheap way to verify the
"payload" of these covenants, i.e. that a transaction is paying a certain,
possibly large, set of addresses certain specific amounts of money. And
even if not, TXHASH+CSFSV would still be the way that eltoo would be
implemented under this proposal.

On Wed, Jan 26, 2022 at 5:16 PM Jeremy <jlrubin at mit.edu> wrote:

> Hi Russell,
>
> Thanks for this email, it's great to see this approach described.
>
> A few preliminary notes of feedback:
>
> 1) a Verify approach can be made to work for OP_TXHASH (even with CTV
> as-is) E.g., suppose a semantic added for a single byte stack[-1] sighash
> flag to read the hash at stack[-2], then the hash can be passed in instead
> of put on the stack. This has the disadvantage of larger witnesses, but the
> advantage of allowing undefined sighash flags to pass for any hash type.
> 2) using the internal key for APO covenants is not an option because it
> makes transaction construction interactive and precludes contracts with a
> NUMS point taproot key. Instead, if you want similar savings, you should
> advocate an OP_GENERATOR which puts G on the stack. Further, an untagged
> APO variant which has split R and S values would permit something like
> <sig> OP_GENERATOR OP_GENERATOR CHECKSIGAPO, which would be only 2 more
> bytes than CTV.
> 3) I count something like 20 different flags in your proposal. As long as
> flags are under 40 bytes (and 32 assuming we want it to be easy) without
> upgrading math this should be feasible to manipulate on the stack
> programmatically. This is ignoring some of the more flexible additions you
> mention about picking which outputs/inputs are included. However, 20 flags
> means that for testing we would want comprehensive tests and understanding
> for ~1 million different flag combos and the behaviors they expose. I think
> this necessitates a formal model of scripting and transaction validity
> properties. Are there any combinations that might be undesirable?
> 4) Just hashing or not hashing isn't actually that flexible, because it
> doesn't natively let you do things like (for example) TLUV. You really do
> need tx operations for directly manipulating the data on the stack to
> construct the hash if you want more flexible covenants. This happens to be
> compatible with either a Verify or Push approach, since you either
> destructure a pushed hash or build up a hash for a verify.
> 5) Flexible hashing has the potential for quadratic hashing bugs. The
> fields you propose seem to be within similar range to work you could cause
> with a regular OP_HASH256, although you'd want to be careful with some of
> the proposed extensions that you don't create risk of quadratic hashing,
> which seems possible with an output selecting opcode unless you cache
> 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 at 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 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 '<ctv_style_flag> TXHASH EQUALVERIFY'. The reverse is also
>> true where '<ctv_style_flag> TXHASH' can be simulated by CTV by
>> '<ctv-result-from-witness-stack> 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.
>>
>> '<anyprevout-pubkey> CHECKSIGVERIFY can be simulated by '<apo_style_flag>
>> TXHASH <pubkey> 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
>> proposal. However, this proposal doesn't preclude the possibility of
>> having CTV added to legacy script in while having TXHASH added to tapscript.
>>
>> For similar reasons, TXHASH is not amenable to extending the set of
>> txflags at a later date. In theory, one could have TXHASH
>> abort-with-success when encountering an unknown set of flags. However,
>> this would make analyzing tapscript much more difficult. Tapscripts would
>> then be able to abort with success or failure depending on the order script
>> fragments are assembled and executed, and getting the order incorrect would
>> be catastrophic. This behavior is manifestly different from the current
>> batch of OP_SUCCESS opcodes that abort-with-success just by their mere
>> presence, whether they would be executed or not.
>>
>> 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 (1) the version is covered; (2) the locktime is
>> covered; (3) txids are covered; (4) sequence numbers are covered; (5) input
>> amounts are covered; (6) input scriptpubkeys are covered; (7) number of
>> inputs is covered; (8) output amounts are covered; (9) output scriptpubkeys
>> are covered; (10) number of outputs is covered; (11) the tapbranch is
>> covered; (12) the tapleaf is covered; (13) the opseparator value is
>> covered; (14) whether all, one, or no inputs are covered; (15) whether all,
>> one or no outputs are covered; (16) whether the one input position is
>> covered; (17) whether the one output position is covered; (18) whether the
>> sighash flags are covered or not (note: whether or not the sighash flags
>> are or are not covered must itself be covered). Possibly specifying which
>> input or output position is covered in the single case and whether the
>> position is relative to the input's position or is an absolute position.
>>
>> That all said, even if other txhash flag modes are needed in the future,
>> adding TXHASH2 always remains an option.
>>
>>
>>
>> Interactions with potential future opcodes::
>>
>> We should give some consideration on how these opcodes may interact with
>> future opcodes such as CAT, rolling SHA256 opcodes, or how it might
>> interface with other covenant opcodes that may do things like, directly
>> push input or output amounts onto the stack for computation purposes,
>> opcodes which have been added to the Elements project.
>>
>> With CAT and/or rolling SHA256 opcodes and/or existing SHA256 opcodes,
>> the CHECKSIGFROMSTACKVERIFY could verify signatures on programmatically
>> assembled messages. Also, in combination with multiple calls to TXHASH,
>> could be used to create signatures that commit to complex subsets of
>> transaction data.
>>
>> If new opcodes are added to push parts of the transaction data direction
>> onto the stack, e.g. OP_INSPECTOUTPUTVALUE, there is perhaps concern that
>> they would obsolete TXHASH, since, in the presence of rolling SHA256
>> opcodes, TXHASH could be simulated. However, given that TXHASH can
>> compactly create a hash of large portions of transaction data, it seems
>> unlikely that TXHASH would fall into disuse. Also, a combination of TXHASH
>> and transaction introspection opcodes can be used to build "*subtractive
>> covenants*".
>>
>> The usual way of building a covenant, which we will call "*additive *
>> *covenants*", is to push all the parts of the transaction data you would
>> like to fix onto the stack, hash it all together, and verify the resulting
>> hash matches a fixed value. Another way of building covenants, which we
>> will call "*subtractive covenants*", is to push all the parts of the
>> transaction data you would like to remain free onto the stack. Then use
>> rolling SHA256 opcodes starting from a fixed midstate that commits to a
>> prefix of the transaction hash data. The free parts are hashed into that
>> midstate. Finally, the resulting hash value is verified to match a value
>> returned by TXHASH. The ability to nicely build subtractive covenants
>> depends on the details of how the TXHASH hash value is constructed,
>> something that I'm told CTV has given consideration to.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220127/97b618df/attachment-0001.html>;

📅 Original date posted:2022-01-26 📝 Original ...

2023-06-07T23:02:49Z

In reply to nevent1q…fc42
_________________________

📅 Original date posted:2022-01-26
📝 Original message: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 '<ctv_style_flag> TXHASH EQUALVERIFY'. The reverse is also
true where '<ctv_style_flag> TXHASH' can be simulated by CTV by
'<ctv-result-from-witness-stack> 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.

'<anyprevout-pubkey> CHECKSIGVERIFY can be simulated by '<apo_style_flag>
TXHASH <pubkey> 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 proposal.
However, this proposal doesn't preclude the possibility of having CTV added
to legacy script in while having TXHASH added to tapscript.

For similar reasons, TXHASH is not amenable to extending the set of txflags
at a later date. In theory, one could have TXHASH abort-with-success when
encountering an unknown set of flags. However, this would make analyzing
tapscript much more difficult. Tapscripts would then be able to abort with
success or failure depending on the order script fragments are assembled
and executed, and getting the order incorrect would be catastrophic. This
behavior is manifestly different from the current batch of OP_SUCCESS
opcodes that abort-with-success just by their mere presence, whether they
would be executed or not.

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 (1) the version is covered; (2) the locktime is
covered; (3) txids are covered; (4) sequence numbers are covered; (5) input
amounts are covered; (6) input scriptpubkeys are covered; (7) number of
inputs is covered; (8) output amounts are covered; (9) output scriptpubkeys
are covered; (10) number of outputs is covered; (11) the tapbranch is
covered; (12) the tapleaf is covered; (13) the opseparator value is
covered; (14) whether all, one, or no inputs are covered; (15) whether all,
one or no outputs are covered; (16) whether the one input position is
covered; (17) whether the one output position is covered; (18) whether the
sighash flags are covered or not (note: whether or not the sighash flags
are or are not covered must itself be covered). Possibly specifying which
input or output position is covered in the single case and whether the
position is relative to the input's position or is an absolute position.

That all said, even if other txhash flag modes are needed in the future,
adding TXHASH2 always remains an option.

Interactions with potential future opcodes::

We should give some consideration on how these opcodes may interact with
future opcodes such as CAT, rolling SHA256 opcodes, or how it might
interface with other covenant opcodes that may do things like, directly
push input or output amounts onto the stack for computation purposes,
opcodes which have been added to the Elements project.

With CAT and/or rolling SHA256 opcodes and/or existing SHA256 opcodes, the
CHECKSIGFROMSTACKVERIFY could verify signatures on programmatically
assembled messages. Also, in combination with multiple calls to TXHASH,
could be used to create signatures that commit to complex subsets of
transaction data.

If new opcodes are added to push parts of the transaction data direction
onto the stack, e.g. OP_INSPECTOUTPUTVALUE, there is perhaps concern that
they would obsolete TXHASH, since, in the presence of rolling SHA256
opcodes, TXHASH could be simulated. However, given that TXHASH can
compactly create a hash of large portions of transaction data, it seems
unlikely that TXHASH would fall into disuse. Also, a combination of TXHASH
and transaction introspection opcodes can be used to build "*subtractive
covenants*".

The usual way of building a covenant, which we will call "*additive *
*covenants*", is to push all the parts of the transaction data you would
like to fix onto the stack, hash it all together, and verify the resulting
hash matches a fixed value. Another way of building covenants, which we
will call "*subtractive covenants*", is to push all the parts of the
transaction data you would like to remain free onto the stack. Then use
rolling SHA256 opcodes starting from a fixed midstate that commits to a
prefix of the transaction hash data. The free parts are hashed into that
midstate. Finally, the resulting hash value is verified to match a value
returned by TXHASH. The ability to nicely build subtractive covenants
depends on the details of how the TXHASH hash value is constructed,
something that I'm told CTV has given consideration to.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220126/1f33d0b3/attachment.html>;

📅 Original date posted:2021-07-07 📝 Original message:On ...

2023-06-07T22:56:33Z

In reply to nevent1q…egnh
_________________________

📅 Original date posted:2021-07-07
📝 Original message:On Wed, Jul 7, 2021 at 9:12 AM Russell O'Connor <roconnor at blockstream.com>
wrote:

>
> On Wed, Jul 7, 2021 at 12:26 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210707/9a33d4a0/attachment.html>;

📅 Original date posted:2021-07-07 📝 Original message:On ...

2023-06-07T22:56:33Z

In reply to nevent1q…x7fx
_________________________

📅 Original date posted:2021-07-07
📝 Original message:On Wed, Jul 7, 2021 at 12:26 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210707/1a038896/attachment.html>;

📅 Original date posted:2021-07-06 📝 Original message:On ...

2023-06-07T22:56:29Z

In reply to nevent1q…uvdm
_________________________

📅 Original date posted:2021-07-06
📝 Original message:On Tue, Jul 6, 2021 at 2:26 AM Billy Tetrud <billy.tetrud at gmail.com> 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
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bip-constraindestination.md>;
> ).
>
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210706/e7b418bc/attachment.html>;

📅 Original date posted:2021-07-05 📝 Original message:Hi ...

2023-06-07T22:56:26Z

In reply to nevent1q…jyc7
_________________________

📅 Original date posted:2021-07-05
📝 Original message: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 at 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 while allowing for a large number
> of use-cases.
>
> (if the above paragraph makes no sense to you, hopefully this Wikipedia
> article will help:
> https://en.wikipedia.org/wiki/Total_functional_programming )
> (basically my argument here is based on academic programming stuff, and
> might not actually matter in real life)
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210705/67abbcb9/attachment-0001.html>;

📅 Original date posted:2021-07-04 📝 Original message:On ...

2023-06-07T22:56:24Z

In reply to nevent1q…kru9
_________________________

📅 Original date posted:2021-07-04
📝 Original message:On Sun, Jul 4, 2021 at 9:02 PM Russell O'Connor <roconnor at blockstream.com>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210704/b5a2a3f1/attachment-0001.html>;

📅 Original date posted:2021-07-04 📝 Original message:Bear ...

2023-06-07T22:56:23Z

In reply to nevent1q…kvma
_________________________

📅 Original date posted:2021-07-04
📝 Original message: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 at 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 while allowing for a large number
> of use-cases.
>
> (if the above paragraph makes no sense to you, hopefully this Wikipedia
> article will help:
> https://en.wikipedia.org/wiki/Total_functional_programming )
> (basically my argument here is based on academic programming stuff, and
> might not actually matter in real life)
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210704/21a239fc/attachment.html>;

📅 Original date posted:2021-07-06 📝 Original message:If the ...

2023-06-07T22:56:19Z

In reply to nevent1q…xwhn
_________________________

📅 Original date posted:2021-07-06
📝 Original message: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 at 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
> - <S> <M> || <R> SWAP <PK> CSFS
>
> Reuse arbitrary R for a specific M (pay to leak key)
> - <R> <S1> <S2> || DUP2 EQUAL NOT VERIFY 2 PICK SWAP <M> DUP TOALTSTACK
> CSFSV FROMALTSTACK CSFS
>
> Verify 2 different messages reuse the same R.
> - <S1> <R> <M1> <S2> <M2> || 2 PICK EQUAL NOT VERIFY 3 PICK <PK> DUP
> TOALTSTACK CSFSV FROMALTSTACK CSFS
>
> Use a R Value signed by an oracle:
> - <S> <M> <S_oracle> <R_oracle> <R> || DUP TOALTSTACK <PK_oracle> CSFSV
> FROMALTSTACK SWAP <PK> CSFS
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210706/d047ffd2/attachment.html>;

📅 Original date posted:2021-07-04 📝 Original message:On ...

2023-06-07T22:56:17Z

In reply to nevent1q…l9pa
_________________________

📅 Original date posted:2021-07-04
📝 Original message:On Sun, Jul 4, 2021 at 1:30 PM Jeremy <jlrubin at mit.edu> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210704/b7f6ae05/attachment.html>;

📅 Original date posted:2021-07-03 📝 Original message:There ...

2023-06-07T22:56:15Z

In reply to nevent1q…kp8d
_________________________

📅 Original date posted:2021-07-03
📝 Original message: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 <jlrubin at mit.edu> 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 <roconnor at blockstream.com>
> 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 at 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: 1542300000
>>> 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 [`<sig>`, `<msg>`, `<pubKey>`] in this order where `<pubKey>` is the top element and
>>> * `<pubKey>` must be a validly encoded public key
>>> * `<msg>` can be any string
>>> * `<sig>` must follow the strict DER encoding as described in [2] and the S-value of `<sig>` 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 [`<sig>`, `<msg>`, `<pubKey>`] from the stack and pushes true onto the stack if `<sig>` is valid with respect to the raw single-SHA256 hash of `<msg>` and `<pubKey>` using the secp256k1 elliptic curve. Otherwise, it pops three elements and pushes false onto the stack in the case that `<sig>` is the empty string and fails in all other cases.
>>>
>>> Nullfail is enforced the same as for OP_CHECKSIG [3]. If the signature does not match the supplied public key and message hash, and the signature is not an empty byte array, the entire script fails.
>>>
>>> ### Opcode Number
>>>
>>> OP_CHECKDATASIG uses the previously unused opcode number 186 (0xba in hex encoding)
>>>
>>> ### SigOps
>>>
>>> Signature operations accounting for OP_CHECKDATASIG shall be calculated the same as OP_CHECKSIG. This means that each OP_CHECKDATASIG shall be counted as one (1) SigOp.
>>>
>>> ### Activation
>>>
>>> Use of OP_CHECKDATASIG, unless occuring in an unexecuted OP_IF branch, will make the transaction invalid if it is included in a block where the median timestamp of the prior 11 blocks is less than 1542300000.
>>>
>>> ### Unit Tests
>>>
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if 15 November 2018 protocol upgrade is not yet activated.
>>> - `<sig> <msg> OP_CHECKDATASIG` fails if there are fewer than 3 items on stack.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if `<pubKey>` is not a validly encoded public key.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if `<sig>` is not a validly encoded signature with strict DER encoding.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if signature `<sig>` is not empty and does not pass the Low S check.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if signature `<sig>` is not empty and does not pass signature validation of `<msg>` and `<pubKey>`.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` pops three elements and pushes false onto the stack if `<sig>` is an empty byte array.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` pops three elements and pushes true onto the stack if `<sig>` is a valid signature of `<msg>` with respect to `<pubKey>`.
>>>
>>> OP_CHECKDATASIGVERIFY Specification
>>> -----------------------------------
>>>
>>> ### Semantics
>>>
>>> OP_CHECKDATASIGVERIFY is equivalent to OP_CHECKDATASIG followed by OP_VERIFY. It leaves nothing on the stack, and will cause the script to fail immediately if the signature check does not pass.
>>>
>>> ### Opcode Number
>>>
>>> OP_CHECKDATASIGVERIFY uses the previously unused opcode number 187 (0xbb in hex encoding)
>>>
>>> ### SigOps
>>>
>>> Signature operations accounting for OP_CHECKDATASIGVERIFY shall be calculated the same as OP_CHECKSIGVERIFY. This means that each OP_CHECKDATASIGVERIFY shall be counted as one (1) SigOp.
>>>
>>> ### Activation
>>>
>>> Use of OP_CHECKDATASIGVERIFY, unless occuring in an unexecuted OP_IF branch, will make the transaction invalid if it is included in a block where the median timestamp of the prior 11 blocks is less than 1542300000.
>>>
>>> ### Unit Tests
>>>
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if 15 November 2018 protocol upgrade is not yet activated.
>>> - `<sig> <msg> OP_CHECKDATASIGVERIFY` fails if there are fewer than 3 item on stack.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY`fails if `<pubKey>` is not a validly encoded public key.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if `<sig>` is not a validly encoded signature with strict DER encoding.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if signature `<sig>` is not empty and does not pass the Low S check.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if `<sig>` is not a valid signature of `<msg>` with respect to `<pubKey>`.
>>> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` pops the top three stack elements if `<sig>` is a valid signature of `<msg>` with respect to `<pubKey>`.
>>>
>>> Sample Implementation [4, 5]
>>> ----------------------------
>>>
>>> ```c++
>>> case OP_CHECKDATASIG:
>>> case OP_CHECKDATASIGVERIFY: {
>>> // Make sure this remains an error before activation.
>>> if ((flags & SCRIPT_ENABLE_CHECKDATASIG) == 0) {
>>> return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
>>> }
>>>
>>> // (sig message pubkey -- bool)
>>> if (stack.size() < 3) {
>>> return set_error(
>>> serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>>> }
>>>
>>> valtype &vchSig = stacktop(-3);
>>> valtype &vchMessage = stacktop(-2);
>>> valtype &vchPubKey = stacktop(-1);
>>>
>>> if (!CheckDataSignatureEncoding(vchSig, flags,
>>> serror) ||
>>> !CheckPubKeyEncoding(vchPubKey, flags, serror)) {
>>> // serror is set
>>> return false;
>>> }
>>>
>>> bool fSuccess = false;
>>> if (vchSig.size()) {
>>> valtype vchHash(32);
>>> CSHA256()
>>> .Write(vchMessage.data(), vchMessage.size())
>>> .Finalize(vchHash.data());
>>> uint256 message(vchHash);
>>> CPubKey pubkey(vchPubKey);
>>> fSuccess = pubkey.Verify(message, vchSig);
>>> }
>>>
>>> if (!fSuccess && (flags & SCRIPT_VERIFY_NULLFAIL) &&
>>> vchSig.size()) {
>>> return set_error(serror, SCRIPT_ERR_SIG_NULLFAIL);
>>> }
>>>
>>> popstack(stack);
>>> popstack(stack);
>>> popstack(stack);
>>> stack.push_back(fSuccess ? vchTrue : vchFalse);
>>> if (opcode == OP_CHECKDATASIGVERIFY) {
>>> if (fSuccess) {
>>> popstack(stack);
>>> } else {
>>> return set_error(serror,
>>> SCRIPT_ERR_CHECKDATASIGVERIFY);
>>> }
>>> }
>>> } break;
>>> ```
>>>
>>> Sample Usage
>>> ------------
>>>
>>> The following example shows a spend and redeem script for a basic use of CHECKDATASIG. This example validates the signature of some data, provides a placeholder where you would then process that data, and finally allows one of 2 signatures to spend based on the outcome of the data processing.
>>>
>>> ### spend script:
>>> ```
>>> push txsignature
>>> push txpubkey
>>> push msg
>>> push sig
>>> ```
>>> ### redeem script:
>>> ```
>>> (txsig, txpubkey msg, sig)
>>> OP_OVER (txsig, txpubkey, msg, sig, msg)
>>> push data pubkey (txsig, txpubkey, msg, sig, msg, pubkey)
>>> OP_CHECKDATASIGVERIFY (txsig, txpubkey, msg)
>>> ```
>>> Now that msg is on the stack top, the script can write predicates on it,
>>> resulting in the message being consumed and a true/false condition left on the stack: (txpubkey, txsig, boolean)
>>> ```
>>> OP_IF (txsig, txpubkey)
>>> OP_DUP (txsig, txpubkey, txpubkey)
>>> OP_HASH160 (txsig, txpubkey, address)
>>> push <p2pkh spend address> (txsig, txpubkey, address, p2pkh spend address)
>>> OP_EQUALVERIFY (txsig, txpubkey)
>>> OP_CHECKSIG
>>> OP_ELSE
>>> (same as if clause but a different <p2pkh spend address>)
>>> OP_ENDIF
>>> ```
>>>
>>> History
>>> -------
>>>
>>> This specification is based on Andrew Stone’s OP_DATASIGVERIFY proposal [6, 7]. It is modified from Stone's original proposal based on a synthesis of all the peer-review and feedback received [8].
>>>
>>> References
>>> ----------
>>>
>>> [1] [OP_CHECKSIG](https://en.bitcoin.it/wiki/OP_CHECKSIG)
>>>
>>> [2] [Strict DER Encoding](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki)
>>>
>>> [3] [Low-S and Nullfail Specification](https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki)
>>>
>>> [4] [Bitcoin ABC implementation](https://reviews.bitcoinabc.org/D1621)
>>>
>>> [5] [Bitcoin ABC implementation update](https://reviews.bitcoinabc.org/D1646)
>>>
>>> [6] [Andrew Stone’s OP_DATASIGVERIFY](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.3.0.0/doc/opdatasigverify.md)
>>>
>>> [7] [Andrew Stone's article on Scripting](https://medium.com/@g.andrew.stone/bitcoin-scripting-applications-decision-based-spending-8e7b93d7bdb9)
>>>
>>> [8] [Peer Review of Andrew Stone's Proposal](https://github.com/bitcoincashorg/bitcoincash.org/pull/10)
>>>
>>>
>>> --
>>> @JeremyRubin <https://twitter.com/JeremyRubin>;
>>> <https://twitter.com/JeremyRubin>;
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210703/e56d5b04/attachment-0001.html>;

📅 Original date posted:2021-07-03 📝 Original message:Hi ...

2023-06-07T22:56:13Z

In reply to nevent1q…3y9w
_________________________

📅 Original date posted:2021-07-03
📝 Original message: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 at 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: 1542300000
> 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 [`<sig>`, `<msg>`, `<pubKey>`] in this order where `<pubKey>` is the top element and
> * `<pubKey>` must be a validly encoded public key
> * `<msg>` can be any string
> * `<sig>` must follow the strict DER encoding as described in [2] and the S-value of `<sig>` 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 [`<sig>`, `<msg>`, `<pubKey>`] from the stack and pushes true onto the stack if `<sig>` is valid with respect to the raw single-SHA256 hash of `<msg>` and `<pubKey>` using the secp256k1 elliptic curve. Otherwise, it pops three elements and pushes false onto the stack in the case that `<sig>` is the empty string and fails in all other cases.
>
> Nullfail is enforced the same as for OP_CHECKSIG [3]. If the signature does not match the supplied public key and message hash, and the signature is not an empty byte array, the entire script fails.
>
> ### Opcode Number
>
> OP_CHECKDATASIG uses the previously unused opcode number 186 (0xba in hex encoding)
>
> ### SigOps
>
> Signature operations accounting for OP_CHECKDATASIG shall be calculated the same as OP_CHECKSIG. This means that each OP_CHECKDATASIG shall be counted as one (1) SigOp.
>
> ### Activation
>
> Use of OP_CHECKDATASIG, unless occuring in an unexecuted OP_IF branch, will make the transaction invalid if it is included in a block where the median timestamp of the prior 11 blocks is less than 1542300000.
>
> ### Unit Tests
>
> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if 15 November 2018 protocol upgrade is not yet activated.
> - `<sig> <msg> OP_CHECKDATASIG` fails if there are fewer than 3 items on stack.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if `<pubKey>` is not a validly encoded public key.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if `<sig>` is not a validly encoded signature with strict DER encoding.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if signature `<sig>` is not empty and does not pass the Low S check.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` fails if signature `<sig>` is not empty and does not pass signature validation of `<msg>` and `<pubKey>`.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` pops three elements and pushes false onto the stack if `<sig>` is an empty byte array.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIG` pops three elements and pushes true onto the stack if `<sig>` is a valid signature of `<msg>` with respect to `<pubKey>`.
>
> OP_CHECKDATASIGVERIFY Specification
> -----------------------------------
>
> ### Semantics
>
> OP_CHECKDATASIGVERIFY is equivalent to OP_CHECKDATASIG followed by OP_VERIFY. It leaves nothing on the stack, and will cause the script to fail immediately if the signature check does not pass.
>
> ### Opcode Number
>
> OP_CHECKDATASIGVERIFY uses the previously unused opcode number 187 (0xbb in hex encoding)
>
> ### SigOps
>
> Signature operations accounting for OP_CHECKDATASIGVERIFY shall be calculated the same as OP_CHECKSIGVERIFY. This means that each OP_CHECKDATASIGVERIFY shall be counted as one (1) SigOp.
>
> ### Activation
>
> Use of OP_CHECKDATASIGVERIFY, unless occuring in an unexecuted OP_IF branch, will make the transaction invalid if it is included in a block where the median timestamp of the prior 11 blocks is less than 1542300000.
>
> ### Unit Tests
>
> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if 15 November 2018 protocol upgrade is not yet activated.
> - `<sig> <msg> OP_CHECKDATASIGVERIFY` fails if there are fewer than 3 item on stack.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY`fails if `<pubKey>` is not a validly encoded public key.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if `<sig>` is not a validly encoded signature with strict DER encoding.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if signature `<sig>` is not empty and does not pass the Low S check.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` fails if `<sig>` is not a valid signature of `<msg>` with respect to `<pubKey>`.
> - `<sig> <msg> <pubKey> OP_CHECKDATASIGVERIFY` pops the top three stack elements if `<sig>` is a valid signature of `<msg>` with respect to `<pubKey>`.
>
> Sample Implementation [4, 5]
> ----------------------------
>
> ```c++
> case OP_CHECKDATASIG:
> case OP_CHECKDATASIGVERIFY: {
> // Make sure this remains an error before activation.
> if ((flags & SCRIPT_ENABLE_CHECKDATASIG) == 0) {
> return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
> }
>
> // (sig message pubkey -- bool)
> if (stack.size() < 3) {
> return set_error(
> serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> }
>
> valtype &vchSig = stacktop(-3);
> valtype &vchMessage = stacktop(-2);
> valtype &vchPubKey = stacktop(-1);
>
> if (!CheckDataSignatureEncoding(vchSig, flags,
> serror) ||
> !CheckPubKeyEncoding(vchPubKey, flags, serror)) {
> // serror is set
> return false;
> }
>
> bool fSuccess = false;
> if (vchSig.size()) {
> valtype vchHash(32);
> CSHA256()
> .Write(vchMessage.data(), vchMessage.size())
> .Finalize(vchHash.data());
> uint256 message(vchHash);
> CPubKey pubkey(vchPubKey);
> fSuccess = pubkey.Verify(message, vchSig);
> }
>
> if (!fSuccess && (flags & SCRIPT_VERIFY_NULLFAIL) &&
> vchSig.size()) {
> return set_error(serror, SCRIPT_ERR_SIG_NULLFAIL);
> }
>
> popstack(stack);
> popstack(stack);
> popstack(stack);
> stack.push_back(fSuccess ? vchTrue : vchFalse);
> if (opcode == OP_CHECKDATASIGVERIFY) {
> if (fSuccess) {
> popstack(stack);
> } else {
> return set_error(serror,
> SCRIPT_ERR_CHECKDATASIGVERIFY);
> }
> }
> } break;
> ```
>
> Sample Usage
> ------------
>
> The following example shows a spend and redeem script for a basic use of CHECKDATASIG. This example validates the signature of some data, provides a placeholder where you would then process that data, and finally allows one of 2 signatures to spend based on the outcome of the data processing.
>
> ### spend script:
> ```
> push txsignature
> push txpubkey
> push msg
> push sig
> ```
> ### redeem script:
> ```
> (txsig, txpubkey msg, sig)
> OP_OVER (txsig, txpubkey, msg, sig, msg)
> push data pubkey (txsig, txpubkey, msg, sig, msg, pubkey)
> OP_CHECKDATASIGVERIFY (txsig, txpubkey, msg)
> ```
> Now that msg is on the stack top, the script can write predicates on it,
> resulting in the message being consumed and a true/false condition left on the stack: (txpubkey, txsig, boolean)
> ```
> OP_IF (txsig, txpubkey)
> OP_DUP (txsig, txpubkey, txpubkey)
> OP_HASH160 (txsig, txpubkey, address)
> push <p2pkh spend address> (txsig, txpubkey, address, p2pkh spend address)
> OP_EQUALVERIFY (txsig, txpubkey)
> OP_CHECKSIG
> OP_ELSE
> (same as if clause but a different <p2pkh spend address>)
> OP_ENDIF
> ```
>
> History
> -------
>
> This specification is based on Andrew Stone’s OP_DATASIGVERIFY proposal [6, 7]. It is modified from Stone's original proposal based on a synthesis of all the peer-review and feedback received [8].
>
> References
> ----------
>
> [1] [OP_CHECKSIG](https://en.bitcoin.it/wiki/OP_CHECKSIG)
>
> [2] [Strict DER Encoding](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki)
>
> [3] [Low-S and Nullfail Specification](https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki)
>
> [4] [Bitcoin ABC implementation](https://reviews.bitcoinabc.org/D1621)
>
> [5] [Bitcoin ABC implementation update](https://reviews.bitcoinabc.org/D1646)
>
> [6] [Andrew Stone’s OP_DATASIGVERIFY](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.3.0.0/doc/opdatasigverify.md)
>
> [7] [Andrew Stone's article on Scripting](https://medium.com/@g.andrew.stone/bitcoin-scripting-applications-decision-based-spending-8e7b93d7bdb9)
>
> [8] [Peer Review of Andrew Stone's Proposal](https://github.com/bitcoincashorg/bitcoincash.org/pull/10)
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210703/ce1d831d/attachment-0001.html>;

📅 Original date posted:2021-06-12 📝 Original message:On ...

2023-06-07T22:54:40Z

In reply to nevent1q…lh0j
_________________________

📅 Original date posted:2021-06-12
📝 Original message:On Sat, Jun 12, 2021 at 3:59 AM Billy Tetrud <billy.tetrud at gmail.com> 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
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#transaction-evaluation>;).
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210612/b68c365f/attachment.html>;

📅 Original date posted:2021-06-11 📝 Original message:On ...

2023-06-07T22:54:39Z

In reply to nevent1q…cavc
_________________________

📅 Original date posted:2021-06-11
📝 Original message:On Fri, Jun 11, 2021 at 7:12 AM James MacWhyte <macwhyte at gmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210611/acb7ba99/attachment.html>;

📅 Original date posted:2021-06-10 📝 Original message:As it ...

2023-06-07T22:54:36Z

In reply to nevent1q…5q8f
_________________________

📅 Original date posted:2021-06-10
📝 Original message: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 <billy.tetrud at gmail.com> 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 <
> roconnor at 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 at 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
>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md>;
>>> .
>>>
>>> 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
>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#transaction-expiry>; 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210610/22b0d8c3/attachment-0001.html>;

📅 Original date posted:2021-06-10 📝 Original message:This ...

2023-06-07T22:54:35Z

In reply to nevent1q…r8mv
_________________________

📅 Original date posted:2021-06-10
📝 Original message: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 at 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
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md>;
> .
>
> 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
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#transaction-expiry>; 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210610/8acbf1df/attachment.html>;

📅 Original date posted:2021-04-16 📝 Original ...

2023-06-07T22:51:42Z

In reply to nevent1q…64tp
_________________________

📅 Original date posted:2021-04-16
📝 Original message: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 at lists.linuxfoundation.org> wrote:

> I have created a BIP which can be found here:
> https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210416/d620ca08/attachment-0001.html>;

📅 Original date posted:2021-04-09 📝 Original ...

2023-06-07T22:51:37Z

In reply to nevent1q…3puj
_________________________

📅 Original date posted:2021-04-09
📝 Original message:>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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210409/fed819a8/attachment.html>;

📅 Original date posted:2021-04-06 📝 Original message:On ...

2023-06-07T22:51:13Z

In reply to nevent1q…l8ka
_________________________

📅 Original date posted:2021-04-06
📝 Original message:On Tue, Apr 6, 2021 at 12:23 PM David A. Harding <dave at dtrt.org> 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".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210406/bdadc623/attachment.html>;

📅 Original date posted:2021-04-06 📝 Original ...

2023-06-07T22:51:11Z

In reply to nevent1q…mhcq
_________________________

📅 Original date posted:2021-04-06
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210406/1049635d/attachment.html>;

📅 Original date posted:2021-04-16 📝 Original ...

2023-06-07T18:31:34Z

In reply to nevent1q…akgv
_________________________

📅 Original date posted:2021-04-16
📝 Original message: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 at lists.linuxfoundation.org> wrote:

> I have created a BIP which can be found here:
> https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210416/d620ca08/attachment-0001.html>;

📅 Original date posted:2021-04-09 📝 Original ...

2023-06-07T18:31:30Z

In reply to nevent1q…q4za
_________________________

📅 Original date posted:2021-04-09
📝 Original message:>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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210409/fed819a8/attachment.html>;

📅 Original date posted:2021-04-06 📝 Original message:On ...

2023-06-07T18:31:10Z

In reply to nevent1q…rrsr
_________________________

📅 Original date posted:2021-04-06
📝 Original message:On Tue, Apr 6, 2021 at 12:23 PM David A. Harding <dave at dtrt.org> 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".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210406/bdadc623/attachment.html>;

📅 Original date posted:2021-04-06 📝 Original ...

2023-06-07T18:31:09Z

In reply to nevent1q…syd3
_________________________

📅 Original date posted:2021-04-06
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210406/1049635d/attachment.html>;

📅 Original date posted:2021-03-06 📝 Original message:Hi ...

2023-06-07T18:30:31Z

In reply to nevent1q…xvz3
_________________________

📅 Original date posted:2021-03-06
📝 Original message: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 at 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 is reached by miners,
> > there will be six months between the time signal tracking starts and when
> > nodes will begin enforcing taproot's rules. This gives the userbase even
> > more time to upgrade than if we had used the most recently proposed start
> > date for a BIP8 activation (~July 23rd).[2]
> >
> > ### Succeed, or fail fast
> >
> > The earlier version of this proposal was documented over 200 days ago[3]
> > and taproot's underlying code was merged into Bitcoin Core over 140 days
> > ago.[4] If we had started Speedy Trial at the time taproot
> > was merged (which is a bit unrealistic), we would've either be less than
> > two months away from having taproot or we would have moved on to the
> > next activation attempt over a month ago.
> >
> > Instead, we've debated at length and don't appear to be any closer to
> > what I think is a widely acceptable solution than when the mailing list
> > began discussing post-segwit activation schemes over a year ago.[5] I
> > think Speedy Trial is a way to generate fast progress that will either
> > end the debate (for now, if activation is successful) or give us some
> > actual data upon which to base future taproot activation proposals.
> >
> > Of course, for those who enjoy the debate, discussion can continue while
> > waiting for the results of Speedy Trial.
> >
> > ### Base activation protocol
> >
> > The idea can be implemented on top of either Bitcoin Core's existing
> > BIP9 code or its proposed BIP8 patchset.[6]
> >
> > - BIP9 uses two time-based[7] parameters, starttime and timeout. Using
> > these values plus a time-based parameter for the minimum activation
> > delay would give three months for miners to activate taproot, but some
> > of that time near the start or the end might not be usable due to
> > signals only being measured in full retarget periods. However, the
> > six month time for users to upgrade their node would be not be
> > affected by either slow or fast block production.
> >
> > BIP9 is already part of Bitcoin Core and I think the changes being
> > proposed would be relatively small, resulting in a small patch that
> > could be easy to review.
> >
> > - BIP8 uses two height-based parameters, startheight and timeoutheight.
> > Using height values would ensure miners had a certain number of
> > retarget periods (6) to lock in taproot and that there'd be a certain
> > number of blocks (about 24,000) until activation, although latest lock
> > in and expected activation could occur moderately earlier or later
> > than the estimated three and six months.
> >
> > BIP8 would likely be used if Speedy Trial fails, so it could be
> > advantageous to base this proposal on BIP8 so that we gain
> > experience running that code in production.
> >
> > For additional discussion about using times versus heights, see today's
> > log for ##taproot-activation.[11]
> >
> > ### Additional concerns
> >
> > - Encourages false signaling: false signaling is when miners signal
> > readiness to enforce rules that their nodes don't actually support.
> > This was partially responsible for a six-block reorg shortly after the
> > final BIP66 activation[8] and was found to still be a problem during
> > the BIP68 lockin period despite BIP9 being designed to avoid it.[9]
> >
> > Because Speedy Trial only gives miners a maximum of three months to
> > signal support for taproot, it may encourage such false signaling. If
> > taproot locks in as a result of their signaling but most of them fail
> > to upgrade by the activation date several months later, unprepared
> > miners could lose large amounts of money and users could see long
> > reorgs (with unupgraded nodes and SPV lite clients potentially losing
> > money).
> >
> > Compared to other activation proposals, I think the only difference is
> > Speedy Trial's short timeline. False signaling is possible with any
> > other proposal and the same problems can occur if miners fail to
> > upgrade for any mandatory activation.
> >
> > ### Additional advantages
> >
> > - No mandatory signaling: at no time are miners required to signal by
> > Speedy Trial. This includes no mandatory signaling during the
> > locked_in period(s), although such signaling will be encouraged (as it
> > was with BIP9[10]).
> >
> > - Party time: to a lesser degree, a benefit mentioned for flag day
> > activation may also apply here: we could get up to six months
> > advanced notice of taproot activation, allowing users, developers, and
> > organizations to prepare software, announcements, and celebrations for
> > that event.
> >
> > ## Implementation details and next steps
> >
> > Initial discussion about implementation may be found in today's
> > ##taproot-activation log.[11] If it appears Speedy Trial may have
> > traction, Russell O'Connor has offered to work on a patch against BIP8
> > implementing it.
> >
> > ## Acknowledgments
> >
> > The original idea for a short-duration attempt was discussed in the
> > ##taproot-activation IRC channel last July and the revised idea saw
> > additional evaluation there this week. Despite growing frustration,
> > discussion has been overwhelmingly constructive, for which all the
> > contributors should be commended. Although this should not in any way
> > imply endorsement, I'm grateful for the review and comments on a draft
> > of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belcher,
> > Jeremy Rubin, Jonas Nick, Luke Dashjr, Michael Folkson, Russell
> > O'Connor, and IRC users maybehuman and proofofkeags
> >
> > ## Footnotes
> >
> > [1]
> https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.E2.80.99s_see_what_happens.2C_BIP8.28false.2C_3m.29
> >
> > [2] A threshold of 1,815/2,016 blocks (90%) in a single retarget period
> > seemed to have near-universal support during the 2021-02-16 IRC
> > meeting. See:
> https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
> >
> > [3]
> https://en.bitcoin.it/w/index.php?title=Taproot_activation_proposals&oldid=68062
> >
> > [4] https://github.com/bitcoin/bitcoin/pull/19953
> >
> > [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
> >
> > [6] https://github.com/bitcoin/bitcoin/pull/19573
> >
> > [7] BIP9's times are based on the median of the past 11 blocks, which
> > usually trails UTC by about 90 minutes but which can trail behind
> > realtime significantly if miners are doing weird things.
> >
> > [8] https://en.bitcoin.it/wiki/July_2015_chain_forks
> >
> > [9]
> https://buildingbitcoin.org/bitcoin-core-dev/log-2016-06-21.html#l-32
> >
> > [10]
> https://github.com/bitcoin/bitcoin/blob/ed25cb58f605ba583c735f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L337-L339
> >
> > [11] http://gnusha.org/taproot-activation/2021-03-05.log
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210306/ac5abbef/attachment-0001.html>;

📅 Original date posted:2021-03-04 📝 Original ...

2023-06-07T18:29:58Z

In reply to nevent1q…hsh3
_________________________

📅 Original date posted:2021-03-04
📝 Original message:Appologies as I've rearranged your comments in my reply.

On Wed, Mar 3, 2021 at 5:14 PM Matt Corallo <lf-lists at mattcorallo.com>
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 we certainly shouldn't be bullied by anyone who comes threatening their
own soft-fork.

Even simply doing nothing may not prevent divergent consensus from
appearing on the network. Playing conservative isn't playing it safe
because there is nothing more conservative than doing nothing, which isn't
guaranteed to be safe in this sense.

Secondly, for the specific concern of people running BIP8 LOT=true clients,
we could start with "Let’s see what happens" with a short 3 or 4 month
signaling period. A short enough signaling period is not "hijackable". We
could add a longer LOCKED_IN period if there are worries about getting
enough nodes upgraded in time for activation. I see other options as well.

I keep being told that miners are ready and willing to activate, and
taproot will probably activate in two months. All we have to do is get
something out the door that does that. If taproot activates in two months,
great. If it fails to activate we will learn so much in so little time.
UASF's will get to say "I told you so" without waiting a year. Users will
get to take active, meaningful and observable steps to demonstrate their
desire for a taproot upgrade. Very little time will be wasted, in
particular we don't have to finish debating how best to handle the unlikely
scenario where taproot doesn't activate right away for whatever reason that
is, an scenario that isn't even likely to occur.

I'm still very optimistic. I see multiple plausible and potentially
acceptable paths towards activation still open and we don't even have to
choose only one. I can hardly wait to look at the forthcoming PRs for
these possibilities.

> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210304/c752f684/attachment.html>;

📅 Original date posted:2021-03-03 📝 Original message:While ...

2023-06-07T18:29:57Z

In reply to nevent1q…yekw
_________________________

📅 Original date posted:2021-03-03
📝 Original message: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 at 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 censorship rules and the no-censorship rules, and its
> pretty obvious that the real bitcoin which most people follow will be
> the chain without censorship.
>
> For example, if a group of users didn't agree with taproot then they
> could create their own counter-flag-day-activation which requires that a
> transaction is included that does an invalid-spend from a taproot output
> in the first block after the flag day height.
>
> This is always possible with any user activated soft fork. In BIP8
> LOT=true it could be done by rejecting block headers with certain
> version bits signalled.
>
>
> == But it will take so long! ==
>
> We seem to be at a deadlock now. This will take less time than any other
> method, because other methods might never happen. BIP8 is dead and from
> what I see there's no other credible plan.
>
> We've already waited years for taproot. I remember listening to talks
> about bitcoin from 2015 of people discussing Schnorr signatures. And
> given how slow segwit and p2sh adoption were its pretty likely that
> we'll waiting a while for taproot to be actually adopted.
>
>
> == A social media blitz could still try to activate it early ==
>
> The brinksmanship only works because miner signalling can make many
> other nodes activate early, even if those other nodes didn't do
> anything. There can't be a game of chicken that puts the bitcoin network
> at risk.
>
> If a group of people did adopt alternative node software which has a
> shorter flag day, they actually have a risk of slow blocks. Because they
> cant trick or force any other nodes to come along with them, they are
> likely to only have a small economy and therefore would lose a lot of
> hashrate. Imagine trading bitcoins for cash in person and instead of
> waiting 10 minutes for a confirmation you have to wait 3 hours because
> the blocks are slow.
>
> Also, the argument for downloading and running a different software only
> to speed up activation is pretty weak. Taproot would activate in ~18
> months, so why are you so impatient that you need it in 6 months? And
> risk slow blocks for you while doing so? The big difference with BIP148
> the segwit UASF, is that people *had to* run some other software
> otherwise they would get *no soft fork at all*.
>
>
> == Without miner signalling how do we know the new rules are even
> activated? ==
>
> When did you see miners signalling their support for the inflation
> schedule?
>
> Bitcoin's rules are enforced by wallets backed by full nodes. You'll
> always know if your own full node is enforcing the new rules. The thing
> that matters isnt miner signalling but your own full node, and the nodes
> of those you trade with.
>
> Flag day activation is quite similar to the way block reward halvenings
> work. At and after block height 630000 miners are only allowed to create
> 6.25 BTC rather than 12.5 BTC. Everyone knows that if miners continued
> to create 12.5 BTC or more they would be unable to sell or spend those
> coins anywhere.
>
> In 2017 when segwit was being activated people created a huge list of
> various bitcoin companies, merchants and wallets:
>
> https://web.archive.org/web/20171228111943/https://bitcoincore.org/en/segwit_adoption/
> Looking at that list, you would know that if someone stole coins from a
> segwit address they would be unable to deposit them in many exchanges
> and merchants: Bitrefill, Bitstamp, Kraken, Localbitcoins, Paxful,
> Vaultoro, HitBTC, etc.
>
> Then what happened is only a month after S2X was beaten this guy moved
> 40000 BTC to a segwit address, confident about the power of the network
> to protect his coins.
>
> https://old.reddit.com/r/Bitcoin/comments/7tcmi4/bitcointalks_famous_user_loaded_moved_his_40k_btc/
>
> If there's ever any doubt about flag day activation we can always draw
> up a similar list, although if there's broad consensus about it then
> there's no reason why bitcoin businesses wouldn't upgrade to the latest
> Core, like they did with every other previous soft fork.
>
>
> == This gives the impression that Core developers control the protocol ==
>
> This objection has a mirror image argument: BIP8 with LOT=false gives
> the impression that miners control the protocol(!)
>
> Eventually some group has to make a decision. We will ask the bitcoin
> economy and users what they think of flag day activation. It's pretty
> clear that nobody seriously objects to taproot, and as described above
> if Core developers did something evil the community could resist it with
> a counter-flag-day-activation.
>
>
>
> == TL;DR ==
>
> I believe flag day activation is the way forward. It should answer all
> the objections and risks which make other methods too controversial.
> Let's go ahead and bring taproot to bitcoin!
>
>
>
> == References ==
>
> [1] -
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html
> luke-jr posts saying LOT=false in his view reintroduces a bug, he
> compares it to introducing an inflation bug and just hoping that miners
> will not exploit it.
>
> [2] -
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018425.html
> This whole thread has many people disagreeing with LOT=true
>
> [3] -
>
> https://old.reddit.com/r/Bitcoin/comments/4biob5/research_into_instantaneous_vote_behavior_in/
>
>
> https://old.reddit.com/r/Bitcoin/comments/3v04pd/can_we_please_have_a_civil_discussion_about/cxjnz1d/?context=1
>
>
> https://old.reddit.com/r/Bitcoin/comments/41ykkt/members_trying_to_destroy_bitcoin_on_this_thread/cz6ccka/?context=3
>
> [4] -
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018495.html
> Matt Corallo's flag day activation proposal
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210303/f33b24c3/attachment-0001.html>;

📅 Original date posted:2020-10-08 📝 Original message:On ...

2023-06-07T18:27:22Z

In reply to nevent1q…uu4q
_________________________

📅 Original date posted:2020-10-08
📝 Original message:On Thu, Oct 8, 2020 at 11:00 AM David A. Harding via bitcoin-dev <
bitcoin-dev at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201008/e79a6702/attachment.html>;

📅 Original date posted:2020-08-03 📝 Original message:With ...

2023-06-07T18:26:10Z

In reply to nevent1q…fv3d
_________________________

📅 Original date posted:2020-08-03
📝 Original message: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 "qqqqqq" 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
<https://github.com/satoshilabs/slips/blob/master/slip-0032.md>; 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200803/67e64b4d/attachment-0001.html>;

📅 Original date posted:2020-07-15 📝 Original message:On ...

2023-06-07T18:25:57Z

In reply to nevent1q…r43f
_________________________

📅 Original date posted:2020-07-15
📝 Original message:On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200715/42e33bf5/attachment.html>;

📅 Original date posted:2020-07-15 📝 Original message:The ...

2023-06-07T18:25:57Z

In reply to nevent1q…xl60
_________________________

📅 Original date posted:2020-07-15
📝 Original message: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 <gsanders87 at gmail.com> 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 at lists.linuxfoundation.org> wrote:
>
>> On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev <
>> bitcoin-dev at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200715/33a67832/attachment.html>;

📅 Original date posted:2020-05-27 📝 Original message:I ...

2023-06-07T18:24:53Z

In reply to nevent1q…rqch
_________________________

📅 Original date posted:2020-05-27
📝 Original message: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 at 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 <gsanders87 at gmail.com>
> 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 at 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 at lists.linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200527/ce628abf/attachment.html>;

📅 Original date posted:2020-05-02 📝 Original message:> ...

2023-06-07T18:24:14Z

In reply to nevent1q…3c0l
_________________________

📅 Original date posted:2020-05-02
📝 Original message:> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200502/6d03957c/attachment.html>;

📅 Original date posted:2020-05-02 📝 Original message:On ...

2023-06-07T18:24:13Z

In reply to nevent1q…ucnr
_________________________

📅 Original date posted:2020-05-02
📝 Original message:On Sat, May 2, 2020 at 10:26 AM Anthony Towns <aj at erisian.com.au> 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 0xFFFFFFFF
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.
-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200502/4a4b2947/attachment.html>;

📅 Original date posted:2020-05-01 📝 Original message:While ...

2023-06-07T18:24:11Z

In reply to nevent1q…txxn
_________________________

📅 Original date posted:2020-05-01
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200501/cc57f1b0/attachment.html>;

📅 Original date posted:2020-03-06 📝 Original message:On ...

2023-06-07T18:23:20Z

In reply to nevent1q…tu4w
_________________________

📅 Original date posted:2020-03-06
📝 Original message:On Wed, Feb 26, 2020 at 2:56 PM Jeremy via bitcoin-dev <
bitcoin-dev at 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 <https://twitter.com/JeremyRubin>;
> <https://twitter.com/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 <https://github.com/roconnor-blockstream/SSS32/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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200306/00d09243/attachment.html>;

📅 Original date posted:2020-03-22 📝 Original message:On ...

2023-06-07T18:23:12Z

In reply to nevent1q…4tex
_________________________

📅 Original date posted:2020-03-22
📝 Original message:On Sun, Mar 22, 2020 at 5:43 AM Tim Ruffing <crypto at timruffing.de> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200322/53768608/attachment-0001.html>;

📅 Original date posted:2020-03-21 📝 Original message:On ...

2023-06-07T18:23:12Z

In reply to nevent1q…j8hu
_________________________

📅 Original date posted:2020-03-21
📝 Original message:On Sat, Mar 21, 2020 at 12:46 PM Tim Ruffing via bitcoin-dev <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200321/33b4ef58/attachment.html>;

📅 Original date posted:2020-02-26 📝 Original message:On ...

2023-06-07T18:23:04Z

In reply to nevent1q…hqrs
_________________________

📅 Original date posted:2020-02-26
📝 Original message:On Sun, Feb 23, 2020 at 11:26 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200225/1f8350fd/attachment.html>;

📅 Original date posted:2019-12-05 📝 Original message:After ...

2023-06-07T18:21:53Z

In reply to nevent1q…2z7g
_________________________

📅 Original date posted:2019-12-05
📝 Original message: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 <https://bitcoin.stackexchange.com/a/85665/49364>; 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 Alice wants to create signatures
that are restricted to a specific combination of C[i]'s and D[i]'s, she
needs to use an exponential number of pubkeys, which isn't tractable to do
in Script. But neither my original proposal nor CODESEPARATOR helps in
this case either because CODESEPARATOR can mark only the last executed
position. Taproot's MAST (Merklized Alternative Script Tree per aj's
suggestion), can maybe provide a tractable solution to this in cases where
it is applicable. The MAST is always a disjunction and because the tapleaf
is signed, it is safe to reuse pubkeys between alternative branches.

This analysis suggests that we should amend CODESEPARATORs behaviour to
update an accumulator (presumably a running hash value), so that all
executed CODESEPARATOR positions end up covered by the signature. That
would provide a solution to the above problem for those cases where
taproot's MAST cannot be used. I'm not sure if it is better to propose
such an amendment to CODESEPARATOR's behaviour now, or to propose to
soft-fork in such optional behaviour at a later time.

However, what I said above was even too simplified. In general, a policy
of the form.

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

where each term could possibly be parameterized by some witness value
(though at the moment there isn't enough functionality in Script to
parameterize the pubkeys in any reasonably way and it maybe isn't even
possible to parameterise the conditions in any reasonable way). In
general, you might want your signature to cover (some function of) this
witness value. This suggests that we would actually want a CODESEPARATOR
variant that pushes a stack item into the accumulator that gets covered by
the signature rather than pushing the CODESEPARATOR position. Though at
this point the name CODESEPARATOR is probably not suitable, even if it
subsumes the functionality. Again, I'm not sure if it is better to propose
such a replacement for CODESEPARATOR's behaviour now, or to propose to
soft-fork in such optional behaviour at a later time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191205/5dc3e915/attachment-0001.html>;

📅 Original date posted:2019-12-01 📝 Original message:On ...

2023-06-07T18:21:52Z

In reply to nevent1q…cjm6
_________________________

📅 Original date posted:2019-12-01
📝 Original message:On Thu, Nov 28, 2019 at 3:07 AM Anthony Towns <aj at erisian.com.au> 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 Script where a signature copying attack can be
performed is adequate by itself to dismiss my proposal. However if you
believe that if we don't save everyone all the time then there is no point
in trying, or if you believe that signing the CHECKSIG position probably
will not protect most users most of the time, or if you believe the burden
on all the other cases is too great, then maybe it is better to rely on
people using CODESEPARATOR.

Given that MAST design of taproot greatly reduces this problem compared to
legacy script, I suppose you could argue that "the burden on all the other
cases is too great" simply because you believe the problematic situation is
now extremely rare.

I still think we ought to choose designs that are safer by default and
include as much user intention within the signed data as we can reasonably
get away, and use other sighash flags for those cases when we need to
exclude data from the signature.

In particular, imagine a world where CODESEPARATOR never existed. We have
this signature copying attack to deal with, and we are designing a new
Segwit version in which we can now address the problem. One proposal that
someone comes up with is to sign the CHECKSIG position (or sign the
enclosing OP_IF/OP_ELSE... position), maybe using a SIGHASH flag to
optionally disable it. Someone else comes up with a proposal to add new
"CODESEPARATOR" opcode which requires adding a new piece of state to the
Script interpreter (the only non-stack based piece of state) to track the
last executed CODESEPARATOR position and include that in the signature.
Would you really prefer the CODESEPARATOR proposal?

> > I believe that it would be safer, and less surprising to users, to
> always sign
> > the CHECKSIG position by default.
>
> > As a side benefit, we get to eliminate CODESEPARATOR, removing a fairly
> awkward
> > opcode from this script version.
>
> As it stands, ANYPREVOUTANYSCRIPT proposes to not sign the script code
> (allowing the signature to be reused in different scripts) but does
> continue signing the CODESEPARATOR position, allowing you to optionally
> restrict how flexibly you can reuse signatures. That seems like a better
> tradeoff than having ANYPREVOUTANYSCRIPT signatures commit to the CHECKSIG
> position which would make it a fair bit harder to design scripts that
> can share signatures, or not having any way to restrict which scripts
> the signature could apply to other than changing the pubkey.
>

Um, I believe that signing the CODESEPERATOR position without signing the
script code is nonsensical. You are talking about signing a piece of data
without an interpretation of its meaning.

Recall that originally CODESEPARTOR would let you sign a suffix of the
Script program. In the context of signing the whole script (which is
always signed indirectly as part of the txid in legacy signatures) signing
the offset into that scripts contains just as much information as signing a
script suffix, while being constant sized. When you remove the Script from
the data being signed, signing an offset is no longer equivalent to signing
a Script suffix, and an offset into an unknown data structure is a
meaningless value by itself. There is no way that you should be signing
CODESEPARATOR position without also covering the Script with the signature.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191201/75cc9af7/attachment.html>;

📅 Original date posted:2019-11-27 📝 Original message:Hi ...

2023-06-07T18:21:51Z

In reply to nevent1q…0vgc
_________________________

📅 Original date posted:2019-11-27
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191127/8cc191b9/attachment.html>;

📅 Original date posted:2019-11-27 📝 Original message:Thanks ...

2023-06-07T18:21:50Z

In reply to nevent1q…7y22
_________________________

📅 Original date posted:2019-11-27
📝 Original message: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 <https://twitter.com/JeremyRubin>;
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191127/4bb82570/attachment.html>;

📅 Original date posted:2019-11-08 📝 Original message:I do ...

2023-06-07T18:21:39Z

In reply to nevent1q…9y92
_________________________

📅 Original date posted:2019-11-08
📝 Original message:I do like the idea of length prefixing the witness program. I will note
that the 1 byte witness version is really more like a 1 character witness
version. There are 17 different segwit versions and there are 32
characters in the bech32 alphabet. That leaves 15 unused characters that
we can use for assigning new meanings too.

That said, it is probably most sensible to define a new
human-readable-prefix for length prefixed bitcoin witness programs. "btc1"
anyone?

On Fri, Nov 8, 2019 at 12:12 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Good morning Pieter, and all,
>
> Can we modify Bech32 SegWit address format for version 1 and above as
> below?
>
> * The data-part values:
> ** 1 byte: the witness version
> + ** If the witness version is non-zero, 1 byte: the length of the
> witness program.
> ** A conversion of the 2-to-40-byte witness program (as defined by [
> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141])
> to base32:
> *** Start with the bits of the witness program, most significant bit
> per byte first.
> *** Re-arrange those bits into groups of 5, and pad with zeroes at
> the end if needed.
> *** Translate those bits to characters using the table above.
>
> This retains the ability of a bech32 address to specify any valid witness
> length and allows future version 1 addresses with lengths other than 32,
> while closing this malleation.
>
> Older software being given the modified v1 address format would mis-send
> it to the wrong witness program, however.
>
> Alternately we could just keep using version 0 in the address format
> forever.
> The requirement would be to ensure that SegWit vN (N >= 1) output witness
> programs would have a data-part value encoded as below:
>
> * The data-part values:
> ** 1 byte: legacy witness version, which must always be 0.
> ** 1 byte: actual witness version, which must be non-zero.
> ** 1 byte: padding length: 0 or 1.
> ** If padding length is 1, 1 byte: padding, which must be 0.
> ** 1 byte: witness program length.
> ** variable: witness program.
>
> A writer for a v1 or later address would initially set an empty padding,
> then compute:
>
> 1 // actual witness version
> + 1 // padding length
> + 1 // witness length
> + witness_length
>
> If the above sum is 20 or 32, then the writer selects a non-zero padding
> and inserts the padding byte so that the above sum is now 21 or 33.
>
> To a reader that understands only bech32 v0, such an encoding would look
> like a SegWit v0 invalid-program-length, and be rejected.
> A reader which understands the above protocol would, instead of rejecting
> a SegWit v0 invalid-program-length, instead attempt to parse it as above
> first, and consider it as SegWit v1 or higher if it was parsed correctly as
> above.
>
> The above proposal is of course ridiculous and I am now currently running
> diagnostics on my processing units to see if further glitches occur in test
> reasoning skills.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191108/7280da70/attachment.html>;

📅 Original date posted:2019-06-26 📝 Original message:I have ...

2023-06-07T18:18:44Z

In reply to nevent1q…wfzc
_________________________

📅 Original date posted:2019-06-26
📝 Original message: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 0x0100000001, 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190626/7223bf9f/attachment.html>;

📅 Original date posted:2019-06-28 📝 Original message:Hmm? ...

2023-06-07T18:18:44Z

In reply to nevent1q…3dpp
_________________________

📅 Original date posted:2019-06-28
📝 Original message: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 Stream, unsigned int N, typename T,
> typename V>
> serialize.h-680-void Unserialize_impl(Stream& is, prevector<N, T>& 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 == 0x02000000 =~ 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 == 0x02000000.
I think I mistook it for SIZE_MAX when reviewing this, or just didn't
notice it at all.

Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190628/e7442a36/attachment.html>;

📅 Original date posted:2019-06-09 📝 Original message:On ...

2023-06-07T18:18:34Z

In reply to nevent1q…5rw9
_________________________

📅 Original date posted:2019-06-09
📝 Original message:On Sat, Jun 8, 2019 at 11:59 PM Rusty Russell <rusty at rustcorp.com.au> wrote:

> "Russell O'Connor" <roconnor at blockstream.io> writes:
> > Hi Rusty,
> >
> > On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev <
> > bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190609/e1605c53/attachment.html>;

📅 Original date posted:2019-06-03 📝 Original message:Hi ...

2023-06-07T18:18:33Z

In reply to nevent1q…2pah
_________________________

📅 Original date posted:2019-06-03
📝 Original message:Hi Rusty,

On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190603/66962193/attachment.html>;

📅 Original date posted:2019-06-25 📝 Original ...

2023-06-07T18:18:30Z

In reply to nevent1q…azdc
_________________________

📅 Original date posted:2019-06-25
📝 Original message: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 <jlrubin at mit.edu> 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 just get rid of it in favor of conditional Verify
> semantics)
>
> And make it clear that because we can add future script versions fairly
> easily, this is a sufficient step.
>
>
> Does that seem in line with your understanding of how this might be done?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190625/870a1cdd/attachment-0001.html>;

📅 Original date posted:2019-06-24 📝 Original message:I ...

2023-06-07T18:18:29Z

In reply to nevent1q…lgvf
_________________________

📅 Original date posted:2019-06-24
📝 Original message: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 <jlrubin at mit.edu> 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 at 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
<https://en.wikipedia.org/wiki/Syntax_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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190624/9d04f319/attachment-0001.html>;

📅 Original date posted:2019-06-24 📝 Original ...

2023-06-07T18:18:28Z

In reply to nevent1q…w8a8
_________________________

📅 Original date posted:2019-06-24
📝 Original message: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 <jeremy.l.rubin at gmail.com>
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 at 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 at 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 at 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 <SIGHASH_ALL> 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190624/f738daa1/attachment-0001.html>;

📅 Original date posted:2019-06-18 📝 Original message:Just ...

2023-06-07T18:18:27Z

In reply to nevent1q…3g9n
_________________________

📅 Original date posted:2019-06-18
📝 Original message: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 at 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 at 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 <SIGHASH_ALL> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190618/783d5ba9/attachment.html>;

📅 Original date posted:2019-06-02 📝 Original message:On ...

2023-06-07T18:18:26Z

In reply to nevent1q…ecu9
_________________________

📅 Original date posted:2019-06-02
📝 Original message:On Sat, Jun 1, 2019 at 12:47 PM Jeremy via bitcoin-dev <
bitcoin-dev at 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<unsigned char>* 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<opcodetype>(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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190602/74ada17f/attachment-0001.html>;

📅 Original date posted:2019-05-24 📝 Original message:In ...

2023-06-07T18:18:20Z

In reply to nevent1q…4pe8
_________________________

📅 Original date posted:2019-05-24
📝 Original message: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 <jlrubin at mit.edu> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190524/868860a9/attachment-0001.html>;

📅 Original date posted:2019-05-29 📝 Original message:On ...

2023-06-07T18:18:19Z

In reply to nevent1q…pkmf
_________________________

📅 Original date posted:2019-05-29
📝 Original message:On Mon, May 27, 2019 at 3:21 AM Anthony Towns <aj at erisian.com.au> 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 Miniscript, and/or just directly implement an enumeration of
policies.

However, my proposal CHECKSIGFROMSTACK (aka CHECKDATASIG) proposal was
based on my argument that CHECKDATASIG covenant abilities wouldn't be
controversial since it was limited to self-recursion and had less than
64-bits of state space. But ZmnSCPxj has shown that my conclusions were
hasty and that self-recursion has access to arbitrarily large amounts of
state space. In light of this, it would appear that self-recursive
covenants is nearly as powerful as arbitrary recursive covenants, and
therefore is nearly as controversial.

So, while I do think that we should add support for recursive covenants to
Bitcoin, we probably not ready to add it yet given the controversy around
the far more innocent ANYPREVOUT. I do think it would be useful to add
support for CAT and CHECKDATASIG in order to implement MPC with penalties,
but perhaps we should support that via a HASH_tapdata digest function
rather than SHA256, in order to avoid any accidental covenants. Of course
doing so would no longer count as "an alternative" proposal to ANYPREVOUT
or COSHV, and simply "an additional" proposal.

> I think you'd need to complicate it a bit further to do the
> ANYPREVOUTANYSCRIPT variant, where you retain the commitment to
> amount/nseq but drop the commitment to tapleaf_hash.
>
> > I feel that this style of generic building blocks truly embodies what is
> meant
> > by "programmable money".
>
> For practical purposes, this doesn't seem like a great level of
> abstraction to me. It's certainly better at "permissionless innovation"
> though.
>
> You could make these constructions a little bit simpler by having a
> "CHECK_SIG_MSG_VERIFY" opcode that accepts [sig msg key], and does "sig
> key CHECKSIGVERIFY" but also checks the the provided msg was what was
> passed into bip-schnorr.
>

The whole point is to keep the functionality simple and let users program
what they want. What we don't want to do is tailor an opcode for the
specific use case we have in mind, because that just comes at the expense
of all the use cases we don't have in mind.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190529/ac866e25/attachment.html>;