Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
Hi Peter, On 2024-01-24 (Wed) at 19:31:07 +, Peter Todd via bitcoin-dev wrote: > It is > expected that CTV would be usually used with anchor outputs to pay fees; by > creating an input of the correct size in a separate transaction and including > it in the CTV-committed transaction; or possibly, via a transaction sponsor > soft-fork. > > This poses a scalability problem: to be genuinely self-sovereign in a protocol > with reactive security, such as Lightning, you must be able to get > transactions > mined within certain deadlines. To do that, you must pay fees. All of the > intended exogenous fee-payment mechanisms for CTV require users to have at > least one UTXO of suitable size to pay for those fees. I understand your reservations with regard to CTV-based protocols for scaling bitcoin and lightning. Fortunately, the "user gotta have a UTXO" concern is readily answered (and you actually gave one answer to approximately the same concern from me when we discussed lightning fees): If the user's balance inside the protocol is not sufficient to pay exit fees then they aren't going to try to exit; so their in-protocol balance can be used to pay fees. With ephemeral anchors throughout the tree, an exiting user would spend their leaf UTXO, and the ephemeral anchors along the path to their leaf to create a package of the necessary fee rate to facilitate their timely exit. Alternatively, users entering into a channel tree protocol (e.g. Timeout Trees) can have their leaf include a second UTXO commitment which would create a fee-paying output exactly when they need it; without causing a scaling problem. Finally, the reality of these protocol proposals is that they are intended to enable users who may never have sufficient funds to pay the full cost to exit the protocol in on chain fees to use bitcoin in a trust-minimized way. To facilitate this, such a protocol could employ fee insurance which would accept claims for fees to pull a specific exit series on chain via any of the mechanisms you describe. This, by the way, would bring more than one user out of the protocol, so even in the worst case it does scale bitcoin by requiring only 1 fee paying UTXO for log_r(n)*(r-1) users to exit. Hope this helps, --Brandon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A proposal for a "PSBT for descriptors" format
Hi Seedhammer, I think the goal of such a format should be that it is already a valid PSBT, or can be trivially converted into one. Ideally, a coordinating device can load the standardized descriptor file, add inputs (PSBTv2) or unsigned TX (PSBTv1), and send it to compatible signing devices without further modification. Seems like the additions to BIP174 would be a PSBT_GLOBAL_DESCRIPTOR with key of | and value of the descriptor encoded as proposed, and then PSBT_GLOBAL_KEY_NAME with key of and value of . Best, --Brandon On 2023-11-23 (Thu) at 22:25:43 +, SeedHammer Team via bitcoin-dev wrote: > Hi, > > At SeedHammer we're interested in standard, compact output descriptors to make > self-contained metal engraved backups feasible. To that end, we're proposing a > descriptor format based on the PSBT binary encoding. The format has not > reached > widespread consensus, never mind adoption, so at this point we're soliciting > comments before formally proposing it as a BIP. > > See [proposal], [implementation] and [playground] for details and examples. > > The format is a binary and compact serialization specification for the > [wallet-policies] BIP. Features: > > - Based on the binary [BIP174] PSBT format, including re-using the compact > PSBT_GLOBAL_XPUB encoding for extended keys. > - The descriptor itself is encoded in the same textual format as described > in BIPs 380-386 (+389). > - Key references (always) use the wallet-policies format @. > - Miniscript is trivially supported, except inline keys are not allowed, and > pk(NAME) expressions are replaced with indexed (@) key references. > - Metadata such as labels and birthdate blocks are encoded as PSBT > map entries. > > Known issues: > > - CBOR vs PSBT. Blockchain Commons believes[0] that a CBOR based format is > better > because it is a widely used binary encoding standard, whereas we believe the > complexity of CBOR doesn't justify its cost compared to the PSBT encoding > already widely supported by wallet software. > - The proposal specifies a separate header and magic; should the format > instead be > an extension to the PSBT format? > > Thanks, > E > > [proposal] https://github.com/BlockchainCommons/Research/issues/135 > [implementation] https://github.com/seedhammer/bip-serialized-descriptors > [playground] https://go.dev/play/p/nouZlbbcEWt > [wallet-policies] > https://github.com/bitcoin/bips/blob/bb98f8017a883262e03127ab718514abf4a5e5f9/bip-wallet-policies.mediawiki > [BIP174] https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki > > [0] > https://github.com/BlockchainCommons/Research/issues/135#issuecomment-1789644032 > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Examining ScriptPubkeys in Bitcoin Script
On 2023-10-20 (Fri) at 14:10:37 +1030, Rusty Russell via bitcoin-dev wrote: > I've done an exploration of what would be required (given > OP_TX/OP_TXHASH or equivalent way of pushing a scriptPubkey on the > stack) to usefully validate Taproot outputs in Bitcoin Script. Such > functionality is required for usable vaults, at least. So you're proposing this direction as an alternative to the more constrained OP_UNVAULT that replaces a specific leaf in the taptree in a specific way? I think the benefits of OP_UNVAULT are pretty big vs. a generic construction (e.g. ability to unvault multiple inputs sharing the same scriptPubkey to the same output). > TL;DR: if we have OP_TXHASH/OP_TX, and add OP_MULTISHA256 (or OP_CAT), > OP_KEYADDTWEAK and OP_LESS (or OP_CONDSWAP), and soft-fork weaken the > OP_SUCCESSx rule (or pop-script-from-stack), we can prove a two-leaf > tapscript tree in about 110 bytes of Script. This allows useful > spending constraints based on a template approach. I agree that this is what is needed. I started pondering this in response to some discussion about the benefits of OP_CAT or OP_2SHA256 for BitVM. Personally I'd use OP_TAGGEDCATHASH that pops a tag (empty tag can be special cased to plain sha256) and a number (n) of elements to hash, then tagged-hashes the following 'n' elements from the stack. Best, --Brandon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Combined CTV+APO to minimal TXHASH+CSFS
> > * If the top item on the stack is not a minimally encoded `OP_0`, `OP_1`, > or > `OP_2`; succeed immediately[^2]. > > I presume this was supposed to go to OP_4 now. Fixed, thanks! > > ### How does the efficiency compare to [bip118][]? > > Just noting BIP118 also allows pubkey of "1" to stand in for the taproot > inner pubkey, which would be a common use-case. "simply" adding an opcode > ala OP_INNER_PUBKEY could also have the same effect of course. Updated the spec for OP_CSFS to replace OP_0 as pubkey with the taproot internal key. That's a great feature to keep! > Also, BIP118 also opens the door for non-APO signatures to have a sighash > digest that commits to additional data, closing a couple of taproot > malleability bugs. See > https://github.com/bitcoin-inquisition/bitcoin/issues/19 for more > discussion along those lines. These aren't make or break, but would be nice > to clean up if possible Agreed. If this proposal moves forward, I will carefully consider the contents of the hash (as shown in the table at the end) for each mode, and add (or remove) committed data. It might be worth having mode 0 (CTVish) commit to the spend_type and annex as well. Thanks much, --Brandon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Combined CTV+APO to minimal TXHASH+CSFS
Quick update to the proposal thanks to James O'Beirne: CTV is 2-bytes less expensive than I thought when used alone. I thought that script success required exactly OP_TRUE not just a CastToBool()=true value on the stack. This means that my proposal is 2 weight units (0.5vBytes) larger than CTV when both are used in Tapscript. --Brandon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Combined CTV+APO to minimal TXHASH+CSFS
Hi list, https://gist.github.com/reardencode/2aa98700b720174598d21989dd46e781 I'm seeking feedback on this proposal to provide the functionality requested by those advocating for bip118 and bip119 in a combined way that retains the low risk associated with each of those separate proposals. At least part of the reason for creating this is similar to my reason for creating bips PR#1472, and my covenant comparo spreadsheet, i.e. to help further the discussion of these proposals and make more clear the similarities and differences between them. https://github.com/bitcoin/bips/pull/1472 https://docs.google.com/spreadsheets/d/1YL5ttNb6-SHS6-C8-1tHwao1_19zNQ-31YWPAHDZgfo/edit It's become clear to me that in large part the separation between advocates of these two proposals stems from a lack of full understanding of their properties. My hope is that this work helps to clarify our thinking about them individually and together, and potentially move toward consensus on a path toward enabling better lightning, vaults, and likely other amazing ways to use bitcoin in the future. --- # Abstract This proposal is an alternative to [bip119][] and [bip118][], providing the functionality of both proposals with no additional overhead in [many cases](#compared-to-non-tapscript-ctv), while clearing certain objections to both, and opening clear upgrade paths. This is, in essence, an initially constrained version of Russel O'Connor's [OP_TXHASH+OP_CSFS proposal][]. We define three new Tapscript-only opcodes. Replacing `OP_SUCCESS80`, `OP_SUCCESS187`, and `OP_SUCCESS188` with `OP_TXHASH`, `OP_CHECKSIGFROMSTACK`, and `OP_CHECKSIGFROMSTACKVERIFY` respectively. # Summary For `OP_TXHASH`, we define exactly 5 methods of hashing the transaction depending on a minimally encoded numeric argument popped from the stack: argument | behavior | - 0 | as in [bip119][] 1 | as in [bip118][] with sighash flag `0x41` 2 | as in [bip118][] with sighash flag `0xc1` 3 | as in [bip118][] with sighash flag `0x43` 4 | as in [bip118][] with sighash flag `0xc3` `OP_CHECKSIGFROMSTACK(VERIFY)` is defined similarly to the [implementation in the Elements project][OP_CHECKSIGFROMSTACK in elements], but does not internally SHA256 hash the data argument. As [bip340][] defines signatures on arbitrary length messages, and these `OP_CHECKSIGFROMSTACK(VERIFY)` are defined only in Tapscript, the internal hashing is unnecessarily restrictive. Users may wish to use pre-hashed values as in this proposal, or non-SHA256 hashes available in script. # Motivation Much ink has been spilled on the discussion of what is next for bitcoin scipt development. The two proposals nearest to consensus are [bip118][] and [bip119][], but the proponents of each disagree about the relative priority and the merrits of the other. Here, we'll briefly outline some of the objections to each and demonstrate how this proposal reduces those objections. We will not discuss the concerns about the introduction of covenants or recursive covenants generally. ## [CTV][bip119] Objections * Not general enough * Inefficient when otherwise validating the hash (e.g. when combined with `OP_CHECKSIGFROMSTACK`) * Uses `OP_NOPx` extension semantics even though `OP_SUCCESSx` is available ## [APO][bip118] Objections * Not general enough * Accidentally enables inefficient, hard to use covenants * Uses new Tapscript key version to avoid accidents ## Solutions * By providing the behavior of both [bip118][] and [bip119][], this proposal is more general than either of those proposals. It also provides explicit upgrade hooks for further generality (e.g. to [full OP_TXHASH][OP_TXHASH+OP_CSFS proposal]). * By splitting the hashing from the validation of [bip119], the hash can be used in ways other than `OP_EQUALVERIFY`. * We use `OP_SUCCESSx` upgrade semantics. * We explicitly enable some of the sighash-based covenants accidentally enabled by [bip118][]. * By using new signature checking opcodes, we do not require the safety of a new Tapscript key version. # Specification ## `OP_TXHASH` When validating Tapscript, the behavior of `OP_SUCCESS80` is modified as follows: * If there is not at least one item on the stack, fail[^1]. * If the top item on the stack is not a minimally encoded `OP_0`, `OP_1`, or `OP_2`; succeed immediately[^2]. * Pop the top item from the stack, and name it `hash_mode` * If `hash_mode` is 0: * Hash the transaction as defined in [bip119][] * Push the resulting hash to the stack * If `hash_mode` is 1: * Hash the transaction as defined in [bip118][] using `sighash_type=0x41` * Push the resulting hash to the stack * If `hash_mode` is 2: * Hash the transaction as defined in [bip118][] using `sighash_type=0xc1` * Push the resulting hash to the stack * If `hash_mode` is 3: * Hash the transaction as defined in [bip118][] using `sighash_type=0x43` * Push the
Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time
On 2023-08-05 (Sat) at 14:06:10 +, Peter Todd via bitcoin-dev wrote: > > bytes | prefix | usable bits | granularity | max expiration > > --||-|-|--- > > 1 | 0b0| 7 | year| 128 years > > 2 | 0b10 | 14 | week| 315 years > > 3 | 0b110 | 21 | day | 5700 years > > 4 | 0b1110 | 28 | block | 5100 years > > 5 | 0b0| 35 | ??? | ??? > > 6 | 0b10 | 42 | ??? | ??? > > 7 | 0b110 | 49 | ??? | ??? > > 8 | 0b1110 | 56 | ??? | ??? > > 1) Having the granularity of the limit depend on *when* the limit is to be > applied in a UX nightmare. It is far simpler to just pick a useful > granularity, > and include enough bytes of integer to work until well into the future. 3 > bytes, 24-bits, of days is 45,000 years. That's plenty. I must not have explained my proposal clearly. The granularity depends not on when it is applied, but on the encoding. For example, the bits 0b0001 encode an expiration 1-year from the epoch of the system. The bits 0b1000 1000 encode an expiration 128 weeks from the epoch. When decoding, the position of the highest `0` bit in the expiration indicates the byte-length, and the granularity. If the expiration's highest bit is `0`, it is 1-byte long, and the bits following the highest `0` encode a number of years. If the first `0` bit is in the second highest position, then it is 2-bytes long and the bits following the highest 0 encode a number of weeks. > 2) Your suggestion would result in a protocol that degrades over time, as the > granularity of *newly* created addresses goes up. This isn't like CTV/CLTV, > where we're creating something now with a limit in the future. 100 years from > now - if silent payments still exists - people will still want to create > silent > payment addresses that expire, say, 30 days in the future. Your suggestion > does > not allow that. My suggestion does degrade over time in one sense: if it is still in use 128 years in the future, users are required to start using at least 2 bytes to encode their expiration instead of 1, even if they only need year granularity. After 315 years they have to start using at least 3 bytes even if they only need week granularity. I'd rather enable users to encode their expirations in 1 or 2 bytes today and degrade by requiring more bytes than require 3 bytes now. Best, --Brandon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time
I agree. Non-expiring addresses are a significant risk to bitcoin users. On 2023-08-04 (Fri) at 17:39:03 +, Peter Todd via bitcoin-dev wrote: > Fixing this is easy: add a 3 byte field to silent payments addresses, encoding > the expiration date in terms of days after some epoch. 2^24 days is 45,000 > years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days is > 180 > years. We'll be lucky if Bitcoin still exists in 180 years. Instead of a fixed width nDays, consider a custom compact encoding with the position of the first 0-bit indicating the number of extension bytes and the encoded granularity. bytes | prefix | usable bits | granularity | max expiration --||-|-|--- 1 | 0b0| 7 | year| 128 years 2 | 0b10 | 14 | week| 315 years 3 | 0b110 | 21 | day | 5700 years 4 | 0b1110 | 28 | block | 5100 years 5 | 0b0| 35 | ??? | ??? 6 | 0b10 | 42 | ??? | ??? 7 | 0b110 | 49 | ??? | ??? 8 | 0b1110 | 56 | ??? | ??? For address expiration, year or week expiration will typically be sufficiently granular, but for rare occasions more granularity can be encoded with longer addresses. This method also degrades cleanly even if the same address format is still in use in 100 or 300 years. I included block-based expiration to enable SP users to match CLTVs embedded in their scripts, e.g. <2 years> OP_CLTV OP_VAULT_RECOVER or <2 years> OP_CLTV OP_CHECKSIG Best, --Brandon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP for OP_VAULT
Hi Gents, > > I don't think replacing the internal-public-key makes sense -- if it > was immediately spendable via the keypath before there's no reason for > it not to be immediately spendable now. > > Slavishly following the current proposal was the idea to make sure all > functionality was captured; I agree with this change. I think we do need to replace the internal key with a hardcoded NUMS point to allow us to batch multiple vault inputs which might have different internal keys but the same OP_FLU/OP_VAULT_TRIGGER script to the same time+template-restricted output. I like that in James' current PR proposal we can explicitly batch via the implied input/output summation rules while avoiding address reuse. If we can retain some or all of that, I think it would be good for on chain efficiency and potentially privacy. My thoughts on batching: Many inputs with different internal keys can be combined to satisfy the total output value for a single output, as long as their scriptpubkeys with FLU and NUMS internal key are equal This enables avoiding address reuse within the vault. Many inputs with the same scriptpubkey can be combined to satisfy a single CTV output template. This allows a user to unfsck themselves if they initiate a withdrawal that cannot be satisfied because they didn't send enough sats to satisfy their template. Best, --Brandon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposal: Wallet Labels Export Format
On 2022-08-24 (Wed) at 11:18:43 +0200, Craig Raw via bitcoin-dev wrote: > I would like to propose a BIP that specifies a format for the export and > import of labels from a wallet. While transferring access to funds across > wallet applications has been made simple through standards such as BIP39, > wallet labels remain siloed and difficult to extract despite their value, > particularly in a privacy context. I like the idea of standardizing the transfer of this valuable information. > The proposed format is a simple two column CSV file, with the reference to > a transaction, address, input or output in the first column, and the label > in the second column. CSV was chosen for its wide accessibility, especially > to users without specific technical expertise. Similarly, the CSV file may > be compressed using the ZIP format, and optionally encrypted using AES. It seems like the format would be more useful if it also included descriptors so that a single file could be used to transfer a wallet. I think such an addition would improve usability for advanced users who might have many such CSVs to manage, and would then be able to more easily select between them. Descriptor,Label pairs could also be useful in the format for the transfer of a wallet with several sub accounts. Thanks, --Brandon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY
Hi Rusty, Thanks for this. Seems like a productive direction to explore. To me, one of the biggest limitations of CTV is that the script is specific to the amount of the input being spent. OP_TX makes it possible, although clumsy, to emulate OP_IN_OUT_AMOUNT, which could be combined with CTV emulation less OPTX_SELECT_OUTPUT_AMOUNT32x2 to allow a single script to be reused. Given that potential, I wonder if OPTX_SELECT_IN_OUT_AMOUNT32x2 would be worth adding to the initial set of flags. With that addition, a small script can be constructed for a relocatable, batchable construction (eg. as a building block for vaults): OPTX_SEPARATELY|OPTX_UNHASHED|OPTX_INPUTNUM OP_TX OP_DUP OPTX_SELECT_VERSION| OPTX_SELECT_LOCKTIME| OPTX_SELECT_INPUT_SINGLE| OPTX_SELECT_INPUT_SCRIPT| OPTX_SELECT_INPUT_NSEQUENCE| OPTX_SELECT_OUTPUT_SINGLE| OPTX_SELECT_OUTPUT_SCRIPTPUBKEY| OPTX_SELECT_IN_OUT_AMOUNT32x2 OP_TX OP_EQUAL * Additional inputs and change outputs can be added * Could commit to 0 fee and still be useful * Arbitrary amounts can be sent to the same script * There is no txid predictability (unlike CTV) * Anyone could rearrange such input/output pairs after broadcast * Not suitable for some uses * Potentially helpful for others Best, --Brandon On 2022-05-10 (Tue) at 20:05:54 +0930, Rusty Russell via bitcoin-dev wrote: > Hi all, > > TL;DR: a v1 tapscript opcode for generic covenants, but > OP_SUCCESS unless it's used a-la OP_CHECKTEMPLATEVERIFY. This gives an > obvious use case, with clean future expansion. OP_NOP4 can be > repurposed in future as a shortcut, if experience shows that to be a > useful optimization. > > (This proposal builds on Russell O'Connor's TXHASH[1], with Anthony > Towns' modification via extending the opcode[2]; I also notice on > re-reading that James Lu had a similar restriction idea[3]). > > Details > --- > > OP_TX, when inside v1 tapscript, is followed by 4 bytes of flags. > Unknown flag patterns are OP_SUCCESS, though for thoroughness some future > potential uses are documented here. Note that pushing more than 1000 > elements on the stack or an element more than 512 bytes will hit the > BIP-342 resource limits and fail. > > Defined bits > > > (Only those marked with * have to be defined for this soft fork; the > others can have semantics later). > > OPTX_SEPARATELY: treat fields separately (vs concatenating) > OPTX_UNHASHED: push on the stack without hashing (vs SHA256 before push) > > - The first nicely sidesteps the lack of OP_CAT, and the latter allows > OP_TXHASH semantics (and avoid stack element limits). > > OPTX_SELECT_VERSION*: version > OPTX_SELECT_LOCKTIME*: nLocktime > OPTX_SELECT_INPUTNUM*: current input number > OPTX_SELECT_INPUTCOUNT*: number of inputs > OPTX_SELECT_OUTPUTCOUNT*: number of outputs > > OPTX_INPUT_SINGLE: if set, pop input number off stack to apply to > OPTX_SELECT_INPUT_*, otherwise iterate through all. > OPTX_SELECT_INPUT_TXID: txid > OPTX_SELECT_INPUT_OUTNUM: txout index > OPTX_SELECT_INPUT_NSEQUENCE*: sequence number > OPTX_SELECT_INPUT_AMOUNT32x2: sats in, as a high-low u31 pair > OPTX_SELECT_INPUT_SCRIPT*: input scriptsig > OPTX_SELECT_INPUT_TAPBRANCH: ? > OPTX_SELECT_INPUT_TAPLEAF: ? > > OPTX_OUTPUT_SINGLE: if set, pop input number off stack to apply to > OPTX_SELECT_OUTPUT_*, otherwise iterate through all. > OPTX_SELECT_OUTPUT_AMOUNT32x2*: sats out, as a high-low u31 pair > OPTX_SELECT_OUTPUT_SCRIPTPUBKEY*: output scriptpubkey > > OPTX_SELECT_19...OPTX_SELECT_31: future expansion. > > OP_CHECKTEMPLATEVERIFY is approximated by the following flags: > OPTX_SELECT_VERSION > OPTX_SELECT_LOCKTIME > OPTX_SELECT_INPUTCOUNT > OPTX_SELECT_INPUT_SCRIPT > OPTX_SELECT_INPUT_NSEQUENCE > OPTX_SELECT_OUTPUTCOUNT > OPTX_SELECT_OUTPUT_AMOUNT32x2 > OPTX_SELECT_OUTPUT_SCRIPTPUBKEY > OPTX_SELECT_INPUTNUM > > All other flag combinations result in OP_SUCCESS. > > Discussion > -- > > By enumerating exactly what can be committed to, it's absolutely clear > what is and isn't committed (and what you need to think about!). > > The bits which separate concatenation and hashing provide a simple > mechanism for template-style (i.e. CTV-style) commitments, or for > programatic treatment of individual elements (e.g. amounts, though the > two s31 style is awkward: a 64-bit push flag could be added in future). > > The lack of double-hashing of scriptsigs and other fields means we > cannot simply re-use hashing done for SIGHASH_ALL. > > The OP_SUCCESS semantic is only valid in tapscript v1, so this does not > allow covenants for v0 segwit or pre-segwit inputs. If covenants prove > useful, dedicated opcodes can be provided for those cases (a-la > OP_CHECKTEMPLATEVERIFY). > > Cheers, > Rusty. > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html > [2] >
Re: [bitcoin-dev] MuSig2 BIP
Hi Laolu, > Finally, can you elaborate a bit on this fragment of the BIP that describes > a "short cut" when a specific signers is meant to send their nonces last: > > > Second, if there is a unique signer who is supposed to send the pubnonce > > last, it is possible to modify nonce generation for this single signer to > > not require high-quality randomness > > My reading here is that if there's a signer that will always send their > nonce last (possibly the responder to an LN funding attempt or a server for > a non-custodial service like Loop), then they don't actually need to > generate real randomness, and can just fully specify all the new optional > arguments? If so then this may end up really simplifying the implementation > of certain protocols since that last party doesn't (?) need to worry about > their nonces as long as all the other (?) parties are using strong > randomness? I believe this was added in response to an email that a co-worker and I sent to Jonas. The idea originated because one of our signers would have a difficult time tracking, restoring, and securely deleting secret nonces across a signing session, so what was important was that the signer not have to retain state, rather than that they not have to provide their own randomness. The result is that the signer also doesn't need to provide randomness though. The important property of the last signer's nonce is that any variation in any other party's nonce, or other values that contribute to the challenge, must uniformly randomize the last signer's nonce. The sentences following the one you quote describe exactly how achieve this, particularly: * Optional arguments become required * extra_in argument must be composed of all other parties' nonces These modifications ensure that if and only if the partial signature will be exactly equal will the same nonce be used in a subsequent signing session. Best, --Brandon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
