Re: [bitcoin-dev] Speedy covenants (OP_CAT2)
Good morning shesek, > On Sat, May 7, 2022 at 5:08 PM ZmnSCPxj via bitcoin-dev > wrote: > > * Even ***with*** `OP_CAT`, the following will enable non-recursive > > covenants without enabling recursive covenants: > > * `OP_CTV`, ... > > * With `OP_CAT`, the following would enable recursive covenants: > > * `OP_CHECKSIGFROMSTACK`, ... > > Why does CTV+CAT not enable recursive covenants while CSFS+CAT does? > > CTV+CAT lets you similarly assert against the outputs and verify that they > match some dynamically constructed script. > > Is it because CTV does not let you have a verified copy of the input's > prevout scriptPubKey on the stack [0], while with OP_CSFS you can because the > signature hash covers it? > > But you don't actually need this for recursion. Instead of having the user > supply the script in the witness stack and verifying it against the input to > obtain the quine, the script can simply contain a copy of itself as an > initial push (minus this push). You can then reconstruct the full script > quine using OP_CAT, as a
Re: [bitcoin-dev] CTV BIP Meeting #8 Notes
Good morning Jorge, > I think people may be scared of potential attacks based on covenants. For > example, visacoin. > But there was a thread with ideas of possible attacks based on covenants. > To me the most scary one is visacoin, specially seeing what happened in > canada and other places lately and the general censorship in the west, the > supposed war on "misinformation" going on (really a war against truth imo, > but whatever) it's getting really scary. But perhaps someone else can be more > scared about a covenant to add demurrage fees to coins or something, I don't > know. > https://bitcointalk.org/index.php?topic=278122 This requires *recursive* covenants. At the time the post was made, no distinction was seen between recursive and non-recursive covenants, which is why the post points out that covenants suck. The idea then was that anything powerful enough to provide covenants would also be powerful enough to provide *recursive* covenants, so there was no distinction made between recursive and non-recursive covenants (the latter was thought to be impossible). However, `OP_CTV` turns out to enable sort-of covenants, but by construction *cannot* provide recursion. It is just barely powerful enough to make a covenant, but not powerful enough to make *recursive* covenants. That is why today we distinguish between recursive and non-recursive covenant opcodes, because we now have opcode designs that provides non-recursive covenants (when previously it was thought all covenant opcodes would provide recursion). `visacoin` can only work as a recursive covenant, thus it is not possible to use `OP_CTV` to implement `visacoin`, regardless of your political views. (I was also misinformed in the past and ignored `OP_CTV` since I thought that, like all the other covenant opcodes, it would enable recursive covenants.) Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Speedy covenants (OP_CAT2)
Good morning Jorge, > Thanks again. > I won't ask anything else about bitcoin, I guess, since it seems my questions > are too "misinforming" for the list. > I also agreed with vjudeu, also too much misinformation on my part to agree > with him, it seems. > I mean, I say that because it doesn't look like my emails are appearing on > the mailing list: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/thread.html#start > > Do any of you now who moderates the mailing list? I would like to ask him > what was wrong with my latest messages. Cannot remember. > Can the censored messages me seen somewhere perhaps? https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/ E.g.: https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/2022-May/000325.html > That way the moderation could be audited. > > This is quite worrying in my opinion. > But I'm biased, perhaps I deserve to be censored. It would still be nice to > understand why, if you can help me. > Now I wonder if this is the first time I was censored or I was censored in > bip8 discussions too, and who else was censored, when, why and by whom. > Perhaps I'm missing something about how the mailing list works and/or are > giving this more importance than it has. Sometimes the moderator is just busy living his or her life to moderate messages within 24 hours. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted
It is quite ironic that yeah, it is quite ironic that the people who are constantly basing their arguments on personal attack are also the ones who complain the most about personal attacks. That's exactly the irony I was trying to convey. Just like some people claim that the only people against bip119 are people ignorant about bip119, I can also claim that everyone against bip8 doesn't really understand it, can't I? The same people who spread the misinformation that bip8 "would be perceived by most users as developers trying to dictate changes" are now complaining about people spreading misinformation about their own proposals. I personally find it as ironic as it can get. I'm glad I'm not the only one who noticed how ironic the whole situation is. How often are the people claiming to be concerned about misinformation precisely the ones who spread the most misinformation? Very ironic indeed. On Fri, May 6, 2022 at 10:07 PM John Tromp via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Fri, 6 May 2022 7:17PM Jorge Tim?n wrote > > But let's not personally attack andreas for his opinions. > > The only reason you don't like bip8 is because you're ignorant about it > and > > you haven't reviewed it enough. > > Can you see the irony in equating "clueless about BIP119" with a > personal attack and then calling Jeremy ignorant about BIP8? > > -John > ___ > 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] CTV BIP Meeting #8 Notes
I think people may be scared of potential attacks based on covenants. For example, visacoin. But there was a thread with ideas of possible attacks based on covenants. To me the most scary one is visacoin, specially seeing what happened in canada and other places lately and the general censorship in the west, the supposed war on "misinformation" going on (really a war against truth imo, but whatever) it's getting really scary. But perhaps someone else can be more scared about a covenant to add demurrage fees to coins or something, I don't know. https://bitcointalk.org/index.php?topic=278122 For example, what if Justin Castro, sorry, Justin Trudeu mandated a visacoin covenant for all withdrawals from canadian exchanges? What if ursula von der mengele, sorry, von der leyen wants to do the same in europe? What if nina Nina Jankowicz decides visacoin covenants are the best way to "stop misinformation"? Covenants can enable many attacks on bitcoin, not just new cool features. Now, perhaps I am crazy for thinking there's a war against truth going on, I don't know. Perhaps most devs and bitcoin users love those lying politicians I mentioned. Perhaps I'm too biased because my political views. Or perhaps the people who don't consider Justin a criminal against humanity are biased. I guess this goes beyond the scope of this mailing list though. Perhaps we should go back to the bitcoin forums to discuss this kind of thing. On Sat, May 7, 2022 at 10:54 AM alicexbt via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Bitcoin Developers, > > Summary for the last CTV meeting: > > Topics: > > 1)APO version of the simple vault > 2)APO as alternative to CTV > 3)fiatjaf's CTV spacechain demo > 4)Compare CTV with other covenant proposals > 5)Recursive covenants > 6)Responding to FUD > > === > APO version of the simple vault > === > > - It is vulnerable to the half-spend problem, where multiple vaulted > outputs (of the same denomination) can be spent together, burning all but > the first to fees. Fixing this requires amending APOAS to cover the current > input index. > - The unvault transaction is third-party malleable (it can have more > inputs added to it). One practical implication is that you can't hand a > list of the unvault txids to a watchtower, you have to tell them which > outpoints to watch which is less privacy-preserving. Fixing this requires > amending APOAS to cover the number of inputs. > Both of these issues are fixed by the BIP 118 changes suggested by > darosior (although they still not officially spec'd afaik), which would > basically make APO have a CTV-equivalent hash mode (minus scriptSig of > other inputs) > - simple-apo-vault could use APO-as-spec'd with > SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, which would solve the half-spend > problem (but not malleability) and have some other interesting properties, > like more natural dynamic fees (add inputs+change) and the ability spend > multiple vaulted outputs together. This would, however, introduce a tx > pinning attack vector and prevent rate-limited vaults. > > === > APO as alternative to CTV > === > > - Current APO is unusable as a CTV alternative, (revised)APO seems to be > as useful as CTV is (plus some extra flexibility from existing sighash > flags) > - Main drawbacks being the additional witness satisfaction cost, the > network-side full-node validation costs of checking a signature instead of > just a hash, and not being segwit0-compatible (meaning, among others, not > quantumphobic-friendly) > - Its about 3x for APO-in-taproot vs CTV-in-taproot. CTV-in-segwitv0 and > CTV-in-bare-spk get you even more savings > - APO is far from being ready, let alone (revised)APO > - APOv2 would be both better for Eltoo and better for CTV, since you can > use a trick to make the signatures smaller > - "layered commitments" is essential for eltoo to be usable or not is > unclear. AJ Towns thinks it is required while Christian Decker thinks it is > not. > > === > fiatjaf's CTV spacechain demo > === > > https://github.com/fiatjaf/simple-ctv-spacechain > > === > Compare CTV with other covenant proposals > === > > Unlike crypto primitves (e.g., BLS vs Schnorr), there's not really > actually a defined way to compare them. So one exercise of value would be > if everyone tries to actually either agree to or come up with their own > framework for comparing covenants. > > Billy Tetrud's email: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020402.html > > - Prefers CTV for several reasons. Mainly because of being simple, > documentation, code, tools,
Re: [bitcoin-dev] Speedy covenants (OP_CAT2)
Thanks a lot for the many clarifications. Yeah, I forgot it wasn't OP_CAT alone, but in combination with other things. I guess this wouldn't be a covenants proposal then. But simplicity would enable covenants too indeed, no? Or did I get that wrong too? On Sat, May 7, 2022 at 5:06 AM ZmnSCPxj wrote: > Good morning Jorge, > > > OP_CAT was removed. If I remember correctly, some speculated that > perhaps it was removed because it could allow covenants.I don't remember > any technical concern about the OP besides enabling covenants.Before it was > a common opinion that covenants shouldn't be enabled in bitcoin because, > despite having good use case, there are some nasty attacks that are enabled > with them too. These days it seems the opinion of the benefits being worth > the dangers is quite generalized. Which is quite understandable given that > more use cases have been thought since then. > > I think the more accurate reason for why it was removed is because the > following SCRIPT of N size would lead to 2^N memory usage: > > OP_1 OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP > OP_CAT OP_DUP OP_CAT ... > > In particular it was removed at about the same time as `OP_MUL`, which has > similar behavior (consider that multiplying two 32-bit numbers results in a > 64-bit number, similar to `OP_CAT`ting a vector to itself). > > `OP_CAT` was removed long before covenants were even expressed as a > possibility. > > Covenants were first expressed as a possibility, I believe, during > discussions around P2SH. > Basically, at the time, the problem was this: > > * Some receivers wanted to use k-of-n multisignature for improved security. > * The only way to implement this, pre-P2SH, was by putting in the > `scriptPubKey` all the public keys. > * The sender is the one paying for the size of the `scriptPubKey`. > * It was considered unfair that the sender is paying for the security of > the receiver. > > Thus, `OP_EVAL` and the P2SH concept was conceived. > Instead of the `scriptPubKey` containing the k-of-n multisignature, you > create a separate script containing the public keys, then hash it, and the > `scriptPubKey` would contain the hash of the script. > By symmetry with the P2PKH template: > > OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG > > The P2SH template would be: > > OP_DUP OP_HASH160 OP_EQUALVERIFY OP_EVAL > > `OP_EVAL` would take the stack top vector and treat it as a Bitcoin SCRIPT. > > It was then pointed out that `OP_EVAL` could be used to create recursive > SCRIPTs by quining using `OP_CAT`. > `OP_CAT` was already disabled by then, but people were talking about > re-enabling it somehow by restricting the output size of `OP_CAT` to limit > the O(2^N) behavior. > > Thus, since then, `OP_CAT` has been associated with ***recursive*** > covenants (and people are now reluctant to re-enable it even with a limit > on its output size, because recursive covenants). > In particular, `OP_CAT` in combination with `OP_CHECKSIGFROMSTACK` and > `OP_CHECKSIG`, you could get a deferred `OP_EVAL` and then use `OP_CAT` too > to quine. > > Because of those concerns, the modern P2SH is now "just a template" with > an implicit `OP_EVAL` of the `redeemScript`, but without any `OP_EVAL` > being actually enabled. > > (`OP_EVAL` cannot replace an `OP_NOP` in a softfork, but it is helpful to > remember that P2SH was pretty much what codified the difference between > softfork and hardfork, and the community at the time was small enough (or > so it seemed) that a hardfork might not have been disruptive.) > > > Re-enabling OP_CAT with the exact same OP would be a hardfork, but > creating a new OP_CAT2 that does the same would be a softfork. > > If you are willing to work in Taproot the same OP-code can be enabled in a > softfork by using a new Tapscript version. > > If you worry about quantum-computing-break, a new SegWit version (which is > more limited than Tapscript versions, unfortunately) can also be used, > creating a new P2WSHv2 (or whatever version) that enables these opcodes. > > > As far a I know, this is the covenants proposal that has been > implemented for the longest time, if that's to be used as a selection > criteria.And as always, this is not incompatible with deploying other > convenant proposals later. > > No, it was `OP_EVAL`, not `OP_CAT`. > In particular if `OP_EVAL` was allowed in the `redeemScript` then it would > enable covenants as well. > It was just pointed out that `OP_CAT` enables recursive covenenats in > combination with `OP_EVAL`-in-`redeemScript`. > > In particular, in combination with `OP_CAT`, `OP_EVAL` not only allows > recursive covenants, but also recursion *within* a SCRIPT i.e. unbounded > SCRIPT execution. > Thus, `OP_EVAL` is simply not going to fly, at all. > > > Personally I find the simplicity proposal the best one among all the > covenant proposals by far, including this one.But I understand that despite > the name, the proposal is harder to review and
Re: [bitcoin-dev] Speedy covenants (OP_CAT2)
On Sat, May 7, 2022 at 5:52 AM wrote: > > Re-enabling OP_CAT with the exact same OP would be a hardfork, but > creating a new OP_CAT2 that does the same would be a softfork. > > We have TapScript for that. OP_CAT is defined as OP_SUCCESS, it can be > re-enabled in a soft-fork way. For now, OP_CAT in TapScript simply means > "anyone can move those coins", so adding some restrictions is all we need > to re-enable this opcode. Introducing OP_CAT2 is not needed at all, unless > it will be totally different, but then it should not be named as OP_CAT2, > but rather as OP_SOMETHING_ELSE, it depends how different it will be from > OP_CAT. > Oh, well, I didn't know any of that. I guess it could be a modification of OP_SUCCESS if it makes sense instead of a new opcode. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Speedy covenants (OP_CAT2)
Good morning Jorge, > Thanks a lot for the many clarifications. > Yeah, I forgot it wasn't OP_CAT alone, but in combination with other things. > I guess this wouldn't be a covenants proposal then. > But simplicity would enable covenants too indeed, no? > Or did I get that wrong too? Yes, it would enable covenants. However, it could also enable *recursive* covenants, depending on what introspection operations are actually implemented (though maybe not? Russell O'Connor should be the one that answers this). It is helpful to delineate between non-recursive covenants from recursive covenants. * Even ***with*** `OP_CAT`, the following will enable non-recursive covenants without enabling recursive covenants: * `OP_CTV` * `SIGHASH_ANYPREVOUT` * With `OP_CAT`, the following would enable recursive covenants: * `OP_EVAL` * `OP_CHECKSIGFROMSTACK` * `OP_TX`/`OP_TXHASH` * ...possibly more. * It is actually *easier* to *design* an opcode which inadvertently supports recursive covenants than to design one which avoids recursive covenants. Recursive covenants are very near to true Turing-completeness. We want to avoid Turing-completeness due to the halting problem being unsolvable for Turing-complete languages. That is, given just a program, we cannot determine for sure if for all possible inputs, it will terminate. It is important in our context (Bitcoin) that any SCRIPT programs we write *must* terminate, or else we run the risk of a DoS on the network. A fair amount of this is theoretical crap, but if you want to split hairs, recursive covenants are *not* Turing-complete, but are instead total functional programming with codata. As a very rough bastardization, a program written in a total functional programming language with codata will always assuredly terminate. However, the return value of a total functional programming language with codata can be another program. An external program (written in a Turing-complete language) could then just keep invoking the interpreter of the total functional programming language with codata (taking the output program and running it, taking *its* output program and running it, ad infinitum, thus effectively able to loop indefinitely. Translated to Bitcoin transactions, a recursive covenant system can force an output to be spent only if the output is spent on a transaction where one of the outputs is the same covenant (possibly with tweaks). Then an external program can keep passing the output program to the Bitcoin SCRIPT interpreter --- by building transactions that spend the previous output. This behavior is still of concern. It may be possible to attack the network by eroding its supply, by such a recursive covenant. -- Common reactions: * We can just limit the number of opcodes we can process and then fail it if it takes too many operations! That way we can avoid DoS! * Yes, this indeed drops it from Turing-complete to total, possibly total functional programming **without** codata. But if it is possible to treat data as code, it may drop it "total but with codata" instead (i.e. recursive covenants). But if you want to avoid recursive covenants while allowing recursive ones (i.e. equivalent to total without codata), may I suggest you instead look at `OP_CTV` and `SIGHASH_ANYPREVOUT`? * What is so wrong with total-with-codata anyway?? So what if the recursive covenant could potentially consume all Bitcoins, nobody will pay to it except as a novelty!! If you want to burn your funds, 1BitcoinEater willingly accepts it! * The burden of proof-of-safety is on the proposer, so if you have some proof that total-with-codata is safe, by construction, then sure, we can add opcodes that may enable recursive covenants, and add `OP_CAT` back in too. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Adding SIGHASH to TXID
Have you seen the inherited ID proposal from John Law on this list? It's a pretty thorough treatment of this type of proposal, curious if you think it overlaps what you had in mind? Honestly, I've yet to fully load in exactly how the applications of it work, but I'd be interested to hear your thoughts. On Sat, May 7, 2022, 4:55 AM vjudeu via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > For now, we have txid:vout as a previous transaction output. This means > that to have a stable TXID, we are forced to use SIGHASH_ALL somewhere, > just to prevent any transaction modifications that can happen during adding > some inputs and outputs. But it seems that new sighashes could be far more > powerful than we expected: it is technically possible to not only remove > previous transaction output by using SIGHASH_ANYPREVOUT. We can do more and > do it better, we could decide, how to calculate this txid at all! > > So, something like SIGHASH_PREVOUT_NONE would be similar to SIGHASH_NONE > (applied to the previous transaction, taken from txid). To have > SIGHASH_ANYPREVOUT, we need to remove absolutely everything, I don't know > any such sighashes, because even SIGHASH_NONE | SIGHASH_ANYONECANPAY will > commit at least to some fields, for example to the locktime. But, if we > introduce SIGHASH_PREVOUT_XYZ flags for all existing sighashes, we would > have this: > > SIGHASH_PREVOUT_NONE > SIGHASH_PREVOUT_SINGLE > SIGHASH_PREVOUT_ALL > SIGHASH_PREVOUT_ANYONECANPAY > > Then, the procedure is as follows: we use txid:vout to find our previous > transaction. Then, we apply those sighashes to this previous transaction, > to form a new txid, that will be checked during every OP_CHECKSIG-based > opcode. In this way, our txid:vout is used just to do transaction lookup, > after that, sighashes can be applied to the previous transaction, so our > txid could remain stable, even if someone will add some inputs and outputs. > > By default, we could use SIGHASH_PREVOUT_ALL, that would mean our > txid:vout remains unchanged. Then, SIGHASH_PREVOUT_SINGLE would obviously > mean, that we want to commit only to this particular previous transaction > output. That would allow adding any new outputs to the previous > transaction, without affecting our replaced txid, but also without blindly > accepting any txid, because some data of the previous transaction would be > still hashed. > > Then, SIGHASH_PREVOUT_NONE is an interesting case, because it would mean > that no outputs of the previous transaction are checked. But still, the > inputs will be! That would mean: "I don't care about in-between addresses, > but I care that it was initiated from these inputs". In this case, it is > possible to choose some input without those flags, and then apply > SIGHASH_PREVOUT_NONE many times, to make sure that everything started from > that input, but everything in-between can be anything. > > All of those three SIGHASH_PREVOUT_XYZ flags could be combined with > SIGHASH_PREVOUT_ANYONECANPAY. That would mean all inputs of the previous > transaction are discarded, except from the input number matching "vout". Or > we could just use SIGHASH_PREVOUT_ANY instead and discard all inputs from > that previous transaction, that could also be combined with other sighashes. > > So, to sum up, by applying sighashes to the previous transaction, instead > of allowing for any transaction, we could still have some control of our > txid, and I think it could be better than just saying "give me any txid, I > will accept that". I think in most cases we don't want to allow any txid: > we want to only "control the flow", just to make sure that our signatures > will sign what we want and will not be invalidated by changing some > transaction inputs and outputs, unrelated to the currently-checked > signature. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Adding SIGHASH to TXID
For now, we have txid:vout as a previous transaction output. This means that to have a stable TXID, we are forced to use SIGHASH_ALL somewhere, just to prevent any transaction modifications that can happen during adding some inputs and outputs. But it seems that new sighashes could be far more powerful than we expected: it is technically possible to not only remove previous transaction output by using SIGHASH_ANYPREVOUT. We can do more and do it better, we could decide, how to calculate this txid at all! So, something like SIGHASH_PREVOUT_NONE would be similar to SIGHASH_NONE (applied to the previous transaction, taken from txid). To have SIGHASH_ANYPREVOUT, we need to remove absolutely everything, I don't know any such sighashes, because even SIGHASH_NONE | SIGHASH_ANYONECANPAY will commit at least to some fields, for example to the locktime. But, if we introduce SIGHASH_PREVOUT_XYZ flags for all existing sighashes, we would have this: SIGHASH_PREVOUT_NONE SIGHASH_PREVOUT_SINGLE SIGHASH_PREVOUT_ALL SIGHASH_PREVOUT_ANYONECANPAY Then, the procedure is as follows: we use txid:vout to find our previous transaction. Then, we apply those sighashes to this previous transaction, to form a new txid, that will be checked during every OP_CHECKSIG-based opcode. In this way, our txid:vout is used just to do transaction lookup, after that, sighashes can be applied to the previous transaction, so our txid could remain stable, even if someone will add some inputs and outputs. By default, we could use SIGHASH_PREVOUT_ALL, that would mean our txid:vout remains unchanged. Then, SIGHASH_PREVOUT_SINGLE would obviously mean, that we want to commit only to this particular previous transaction output. That would allow adding any new outputs to the previous transaction, without affecting our replaced txid, but also without blindly accepting any txid, because some data of the previous transaction would be still hashed. Then, SIGHASH_PREVOUT_NONE is an interesting case, because it would mean that no outputs of the previous transaction are checked. But still, the inputs will be! That would mean: "I don't care about in-between addresses, but I care that it was initiated from these inputs". In this case, it is possible to choose some input without those flags, and then apply SIGHASH_PREVOUT_NONE many times, to make sure that everything started from that input, but everything in-between can be anything. All of those three SIGHASH_PREVOUT_XYZ flags could be combined with SIGHASH_PREVOUT_ANYONECANPAY. That would mean all inputs of the previous transaction are discarded, except from the input number matching "vout". Or we could just use SIGHASH_PREVOUT_ANY instead and discard all inputs from that previous transaction, that could also be combined with other sighashes. So, to sum up, by applying sighashes to the previous transaction, instead of allowing for any transaction, we could still have some control of our txid, and I think it could be better than just saying "give me any txid, I will accept that". I think in most cases we don't want to allow any txid: we want to only "control the flow", just to make sure that our signatures will sign what we want and will not be invalidated by changing some transaction inputs and outputs, unrelated to the currently-checked signature. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Speedy covenants (OP_CAT2)
> Re-enabling OP_CAT with the exact same OP would be a hardfork, but creating a > new OP_CAT2 that does the same would be a softfork. We have TapScript for that. OP_CAT is defined as OP_SUCCESS, it can be re-enabled in a soft-fork way. For now, OP_CAT in TapScript simply means "anyone can move those coins", so adding some restrictions is all we need to re-enable this opcode. Introducing OP_CAT2 is not needed at all, unless it will be totally different, but then it should not be named as OP_CAT2, but rather as OP_SOMETHING_ELSE, it depends how different it will be from OP_CAT. > OP_1 OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT > OP_DUP OP_CAT ... So we can use OP_SUBSTR instead. Maybe even OP_SPLIT will be enough, if data expansion is the only problem, then we can focus on getting it smaller. Or better, we could use OP_FIND that would return true/false answer if element A is a part of element B, when we do byte-to-byte comparison. In general, we can use many different string-based functions to do the same things, we can choose something that will not exponentially explode as OP_CAT. > It was considered unfair that the sender is paying for the security of the > receiver. It can be changed by using different sighashes, for example, it is possible to create a "negative fee transaction", where all transaction costs are paid by receiver. Using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY with a higher amount in outputs than inputs is enough to do that, see testnet3 transaction 495d2007ae8b741c70c3d278c02ce03702223b9675e954ecabbb634c6cd5bf40. On 2022-05-07 05:06:46 user ZmnSCPxj via bitcoin-dev wrote: > Good morning Jorge, > OP_CAT was removed. If I remember correctly, some speculated that perhaps it > was removed because it could allow covenants.I don't remember any technical > concern about the OP besides enabling covenants.Before it was a common > opinion that covenants shouldn't be enabled in bitcoin because, despite > having good use case, there are some nasty attacks that are enabled with them > too. These days it seems the opinion of the benefits being worth the dangers > is quite generalized. Which is quite understandable given that more use cases > have been thought since then. I think the more accurate reason for why it was removed is because the following SCRIPT of N size would lead to 2^N memory usage: OP_1 OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT ... In particular it was removed at about the same time as `OP_MUL`, which has similar behavior (consider that multiplying two 32-bit numbers results in a 64-bit number, similar to `OP_CAT`ting a vector to itself). `OP_CAT` was removed long before covenants were even expressed as a possibility. Covenants were first expressed as a possibility, I believe, during discussions around P2SH. Basically, at the time, the problem was this: * Some receivers wanted to use k-of-n multisignature for improved security. * The only way to implement this, pre-P2SH, was by putting in the `scriptPubKey` all the public keys. * The sender is the one paying for the size of the `scriptPubKey`. * It was considered unfair that the sender is paying for the security of the receiver. Thus, `OP_EVAL` and the P2SH concept was conceived. Instead of the `scriptPubKey` containing the k-of-n multisignature, you create a separate script containing the public keys, then hash it, and the `scriptPubKey` would contain the hash of the script. By symmetry with the P2PKH template: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG The P2SH template would be: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_EVAL `OP_EVAL` would take the stack top vector and treat it as a Bitcoin SCRIPT. It was then pointed out that `OP_EVAL` could be used to create recursive SCRIPTs by quining using `OP_CAT`. `OP_CAT` was already disabled by then, but people were talking about re-enabling it somehow by restricting the output size of `OP_CAT` to limit the O(2^N) behavior. Thus, since then, `OP_CAT` has been associated with ***recursive*** covenants (and people are now reluctant to re-enable it even with a limit on its output size, because recursive covenants). In particular, `OP_CAT` in combination with `OP_CHECKSIGFROMSTACK` and `OP_CHECKSIG`, you could get a deferred `OP_EVAL` and then use `OP_CAT` too to quine. Because of those concerns, the modern P2SH is now "just a template" with an implicit `OP_EVAL` of the `redeemScript`, but without any `OP_EVAL` being actually enabled. (`OP_EVAL` cannot replace an `OP_NOP` in a softfork, but it is helpful to remember that P2SH was pretty much what codified the difference between softfork and hardfork, and the community at the time was small enough (or so it seemed) that a hardfork might not have been disruptive.) > Re-enabling OP_CAT with the exact same OP would be a hardfork, but creating a > new OP_CAT2 that does the same would be a softfork. If
[bitcoin-dev] CTV BIP Meeting #8 Notes
Hi Bitcoin Developers, Summary for the last CTV meeting: Topics: 1)APO version of the simple vault 2)APO as alternative to CTV 3)fiatjaf's CTV spacechain demo 4)Compare CTV with other covenant proposals 5)Recursive covenants 6)Responding to FUD === APO version of the simple vault === - It is vulnerable to the half-spend problem, where multiple vaulted outputs (of the same denomination) can be spent together, burning all but the first to fees. Fixing this requires amending APOAS to cover the current input index. - The unvault transaction is third-party malleable (it can have more inputs added to it). One practical implication is that you can't hand a list of the unvault txids to a watchtower, you have to tell them which outpoints to watch which is less privacy-preserving. Fixing this requires amending APOAS to cover the number of inputs. Both of these issues are fixed by the BIP 118 changes suggested by darosior (although they still not officially spec'd afaik), which would basically make APO have a CTV-equivalent hash mode (minus scriptSig of other inputs) - simple-apo-vault could use APO-as-spec'd with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, which would solve the half-spend problem (but not malleability) and have some other interesting properties, like more natural dynamic fees (add inputs+change) and the ability spend multiple vaulted outputs together. This would, however, introduce a tx pinning attack vector and prevent rate-limited vaults. === APO as alternative to CTV === - Current APO is unusable as a CTV alternative, (revised)APO seems to be as useful as CTV is (plus some extra flexibility from existing sighash flags) - Main drawbacks being the additional witness satisfaction cost, the network-side full-node validation costs of checking a signature instead of just a hash, and not being segwit0-compatible (meaning, among others, not quantumphobic-friendly) - Its about 3x for APO-in-taproot vs CTV-in-taproot. CTV-in-segwitv0 and CTV-in-bare-spk get you even more savings - APO is far from being ready, let alone (revised)APO - APOv2 would be both better for Eltoo and better for CTV, since you can use a trick to make the signatures smaller - "layered commitments" is essential for eltoo to be usable or not is unclear. AJ Towns thinks it is required while Christian Decker thinks it is not. === fiatjaf's CTV spacechain demo === https://github.com/fiatjaf/simple-ctv-spacechain === Compare CTV with other covenant proposals === Unlike crypto primitves (e.g., BLS vs Schnorr), there's not really actually a defined way to compare them. So one exercise of value would be if everyone tries to actually either agree to or come up with their own framework for comparing covenants. Billy Tetrud's email: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020402.html - Prefers CTV for several reasons. Mainly because of being simple, documentation, code, tools, review and testing. - Everything else either introduces malleability, infinite recursion, or has interactions with other proposed opcodes that could introduce potentially undesirable effects like those. - Anything involving OP_CAT is out for the time being. There are so many things it can enable that it seems most people aren't comfortable adding it at the moment. - APO wallet vaults seem rather hacky, inefficient, and limited. - TLUV is built for evictions, TLUV + IN_OUT_AMOUNT and OP_CHECKOUTPUTVERIFY allows recursive covenants === Recursive covenants === jamesob: I don't particularly understand the aversion to infinite recursion, which seems no different than the risk of potentially burning your coins. It's not like infinite recursion on bitcoin is some kind of DoS vector or poses execution overhead like an Ethereum VM bug might. rgrant: i think people who want recursion for cool stuff are worried that pedestrian stuff will prevent it. jeremyrubin: i think people are afraid of weird shit happening, less so of recursion in particular hsjoberg: "Recursive covenants" is the boogie man shesek: "recursion" translates to "complex black magic" for nondevs' -- recursion is the new turing completeness === Responding to FUD === - It could be a good idea to include showing a way to do blacklists in the bug bounty offer - The potential concerns about recursive covenants have to clearly explained so they can be properly examined. - An article
