Re: [bitcoin-dev] Proposed BIP for OP_CAT
Andrew Poelstra writes:
> I had a similar thought. But my feeling is that replacing the stack
> interpreter data structure is still too invasive to justify the benefit.
>
> Also, one of my favorite things about this BIP is the tiny diff.
To be fair, this diff is even smaller than the OP_CAT diff :)
Though I had to strongly resist refactoring, that interpreter code
needs a good shake! Using a class for the stack is worth doing anyway
(macros, really??).
diff --git a/src/script/interpreter.cpp b/src/script/interpreter.cpp
index dcaf28c2472..2ee2034115f 100644
--- a/src/script/interpreter.cpp
+++ b/src/script/interpreter.cpp
@@ -403,6 +403,19 @@ static bool EvalChecksig(const valtype& sig, const
valtype& pubkey, CScript::con
assert(false);
}
+// First 520 bytes is free, after than you consume an extra slot!
+static size_t effective_size(const std::vector >&
stack)
+{
+size_t esize = stack.size();
+
+for (const auto& v : stack)
+{
+if (v.size() > MAX_SCRIPT_ELEMENT_SIZE)
+esize += (v.size() - 1) / MAX_SCRIPT_ELEMENT_SIZE;
+}
+return esize;
+}
+
bool EvalScript(std::vector >& stack, const
CScript& script, unsigned int flags, const BaseSignatureChecker& checker,
SigVersion sigversion, ScriptExecutionData& execdata, ScriptError* serror)
{
static const CScriptNum bnZero(0);
@@ -1239,7 +1252,7 @@ bool EvalScript(std::vector >&
stack, const CScript&
}
// Size limits
-if (stack.size() + altstack.size() > MAX_STACK_SIZE)
+if (effective_size(stack) + effective_size(altstack) >
MAX_STACK_SIZE)
return set_error(serror, SCRIPT_ERR_STACK_SIZE);
}
}
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinals BIP PR
Hi Luke, > Maybe we need a 3rd BIP editor. Both Kalle and myself haven't had time > to keep up. There are several PRs far more important than Ordinals > nonsense that need to be triaged and probably merged. I don't think adding another editor solves the problem discussed in this thread. Last time we had similar situation and Kalle was added as editor instead of making BIP process decentralized. It was discussed in this [thread][0]. BIP editors can have personal opinions and bias but if it affects PRs getting merged, then repo has no use except for a few developers. > The issue with Ordinals is that it is actually unclear if it's eligible > to be a BIP at all, since it is an attack on Bitcoin rather than a > proposed improvement. What makes it an attack on bitcoin? Some users want to use their money in a different way. How is it different from taproot assets and other standards to achieve similar goals? Some users and developers believe drivechain is an attack on bitcoin, BIP 47 is considered bad, use of OP_RETURN in colored coins is controversial, increasing blocksize is not an improvement etc. Still these BIPs exist in the same repository. > proposed improvement. There is a debate on the PR whether the > "technically unsound, ..., or not in keeping with the Bitcoin > philosophy." or "must represent a net improvement." clauses (BIP 2) are > relevant. Those issues need to be resolved somehow before it could be > merged. Can we remove terms like "philosophy", "net improvement" etc. from BIP 2? Because they could mean different things for different people. [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018859.html /dev/fd0 floppy disk guy Sent with Proton Mail secure email. --- Original Message --- On Monday, October 23rd, 2023 at 11:59 PM, Luke Dashjr via bitcoin-dev wrote: > Everything standardized between Bitcoin software is eligible to be and > should be a BIP. I completely disagree with the claim that it's used for > too many things. > > SLIPs exist for altcoin stuff. They shouldn't be used for things related > to Bitcoin. > > BOLTs also shouldn't have ever been a separate process and should really > just get merged into BIPs. But at this point, that will probably take > quite a bit of effort, and obviously cooperation and active involvement > from the Lightning development community. > > Maybe we need a 3rd BIP editor. Both Kalle and myself haven't had time > to keep up. There are several PRs far more important than Ordinals > nonsense that need to be triaged and probably merged. > > The issue with Ordinals is that it is actually unclear if it's eligible > to be a BIP at all, since it is an attack on Bitcoin rather than a > proposed improvement. There is a debate on the PR whether the > "technically unsound, ..., or not in keeping with the Bitcoin > philosophy." or "must represent a net improvement." clauses (BIP 2) are > relevant. Those issues need to be resolved somehow before it could be > merged. I have already commented to this effect and given my own > opinions on the PR, and simply pretending the issues don't exist won't > make them go away. (Nor is it worth the time of honest people to help > Casey resolve this just so he can further try to harm/destroy Bitcoin.) > > Luke > > > On 10/23/23 13:43, Andrew Poelstra via bitcoin-dev wrote: > > > On Mon, Oct 23, 2023 at 03:35:30PM +, Peter Todd via bitcoin-dev wrote: > > > > > I have not requested a BIP for OpenTimestamps, even though it is of much > > > wider relevance to Bitcoin users than Ordinals by virtue of the fact that > > > much > > > of the commonly used software, including Bitcoin Core, is timestamped > > > with OTS. > > > I have not, because there is no need to document every single little > > > protocol > > > that happens to use Bitcoin with a BIP. > > > > > > Frankly we've been using BIPs for too many things. There is no avoiding > > > the act > > > that BIP assignment and acceptance is a mark of approval for a protocol. > > > Thus > > > we should limit BIP assignment to the minimum possible: extremely > > > widespread > > > standards used by the entire Bitcoin community, for the core mission of > > > Bitcoin. > > > > This would eliminate most wallet-related protocols e.g. BIP69 (sorted > > keys), ypubs, zpubs, etc. I don't particularly like any of those but if > > they can't be BIPs then they'd need to find another spec repository > > where they wouldn't be lost and where updates could be tracked. > > > > The SLIP repo could serve this purpose, and I think e.g. SLIP39 is not a BIP > > in part because of perceived friction and exclusivity of the BIPs repo. > > But I'm not thrilled with this situation. > > > > In fact, I would prefer that OpenTimestamps were a BIP :). > > > > > It's notable that Lightning is not standardized via the BIP process. I > > > think > > > that's a good thing. While it's arguably of wide enough use to warrent > > > BIPs, > > >
Re: [bitcoin-dev] Proposed BIP for OP_CAT
On Tue, Oct 24, 2023 at 11:18:24AM +1030, Rusty Russell wrote: > Andrew Poelstra writes: > >> 3. Should we restrict elsewhere instead? After all, OP_CAT doesn't > >>change total stack size, which is arguably the real limit? > >> > > > > Interesting thought. Right now the stack size is limited to 1000 > > elements of 520 bytes each, which theoretically means a limit of 520k. > > Bitcoin Core doesn't explicitly count the "total stack size" in the > > sense that you're suggesting; it just enforces these two limits > > separately. > > BTW, I'm just learning of the 1000 element limit; I couldn't see it on > scanning BIP-141. > This limit is very old and predates segwit. It might predate P2SH. > > I think trying to add a "total stack size limit" (which would have to > > live alongside the two existing limits; we can't replace them without > > a whole new Tapscript version) would add a fair bit of accounting > > complextiy and wind up touching almost every other opcode...probably > > not worth the added consensus logic. > > Simplest thing I can come up with: > > - instead of counting simple stack depth, count each stack entry as > (1 + /520) entries? You can still only push 520 bytes, so you > can only make these with OP_CAT. > > Looking in interpreter.cpp, `stack` and `altstack` now need to be > objects to count entries differently (not vectors), but it seems like > it'd be simple enough, and the logic could be enabled unconditionally > since it Cannot Be Violated prior to OP_CAT. > I had a similar thought. But my feeling is that replacing the stack interpreter data structure is still too invasive to justify the benefit. Also, one of my favorite things about this BIP is the tiny diff. -- 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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposed BIP for OP_CAT
Andrew Poelstra writes: > On Mon, Oct 23, 2023 at 12:43:10PM +1030, Rusty Russell via bitcoin-dev wrote: >> Ethan Heilman via bitcoin-dev writes: >> > Hi everyone, >> > >> > We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode. >> > https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki >> >> 520 feels quite small for script templates (mainly because OP_CAT itself >> makes Script more interesting!). For example, using OP_TXHASH and >> OP_CAT to enforce that two input amounts are equal to one output amount >> takes about 250 bytes of Script[2] :( >> >> So I have to ask: >> >> 1. Do other uses feel like 520 is too limiting? > > In my view, 520 feels limiting provided that we lack rolling sha2 > opcodes. If we had those, then arguably 65 bytes is enough. Without > them, I'm not sure that any value is "enough". For CHECKSIGFROMSTACK > emulation purposes ideally we'd want the ability to construct a full > transaction on the stack, which in principle would necessitate a 4M > limit. I haven't yet found a desire for rolling sha2: an `OP_MULTISHA256` has been sufficient for my templating investigations w/ OP_TXHASH. In fact, I prefer it to OP_CAT, but OP_CAT does allow your Schnorr sig trick :) >> 2. Was there a concrete rationale for maintaining 520 bytes? 10k is the >> current >>script limit, can we get closer to that? :) > > But as others have said, 520 bytes is the existing stack element limit > and minimizing changes seems like a good strategy to get consensus. (On > the other hand, it's been a few days without any opposition so maybe we > should be more agressive :)). It's probably worth *thinking* about, yes. >> 3. Should we restrict elsewhere instead? After all, OP_CAT doesn't >>change total stack size, which is arguably the real limit? >> > > Interesting thought. Right now the stack size is limited to 1000 > elements of 520 bytes each, which theoretically means a limit of 520k. > Bitcoin Core doesn't explicitly count the "total stack size" in the > sense that you're suggesting; it just enforces these two limits > separately. BTW, I'm just learning of the 1000 element limit; I couldn't see it on scanning BIP-141. > I think trying to add a "total stack size limit" (which would have to > live alongside the two existing limits; we can't replace them without > a whole new Tapscript version) would add a fair bit of accounting > complextiy and wind up touching almost every other opcode...probably > not worth the added consensus logic. Simplest thing I can come up with: - instead of counting simple stack depth, count each stack entry as (1 + /520) entries? You can still only push 520 bytes, so you can only make these with OP_CAT. Looking in interpreter.cpp, `stack` and `altstack` now need to be objects to count entries differently (not vectors), but it seems like it'd be simple enough, and the logic could be enabled unconditionally since it Cannot Be Violated prior to OP_CAT. Cheers, Rusty. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinals BIP PR
Everything standardized between Bitcoin software is eligible to be and should be a BIP. I completely disagree with the claim that it's used for too many things. SLIPs exist for altcoin stuff. They shouldn't be used for things related to Bitcoin. BOLTs also shouldn't have ever been a separate process and should really just get merged into BIPs. But at this point, that will probably take quite a bit of effort, and obviously cooperation and active involvement from the Lightning development community. Maybe we need a 3rd BIP editor. Both Kalle and myself haven't had time to keep up. There are several PRs far more important than Ordinals nonsense that need to be triaged and probably merged. The issue with Ordinals is that it is actually unclear if it's eligible to be a BIP at all, since it is an attack on Bitcoin rather than a proposed improvement. There is a debate on the PR whether the "technically unsound, ..., or not in keeping with the Bitcoin philosophy." or "must represent a net improvement." clauses (BIP 2) are relevant. Those issues need to be resolved somehow before it could be merged. I have already commented to this effect and given my own opinions on the PR, and simply pretending the issues don't exist won't make them go away. (Nor is it worth the time of honest people to help Casey resolve this just so he can further try to harm/destroy Bitcoin.) Luke On 10/23/23 13:43, Andrew Poelstra via bitcoin-dev wrote: On Mon, Oct 23, 2023 at 03:35:30PM +, Peter Todd via bitcoin-dev wrote: I have _not_ requested a BIP for OpenTimestamps, even though it is of much wider relevance to Bitcoin users than Ordinals by virtue of the fact that much of the commonly used software, including Bitcoin Core, is timestamped with OTS. I have not, because there is no need to document every single little protocol that happens to use Bitcoin with a BIP. Frankly we've been using BIPs for too many things. There is no avoiding the act that BIP assignment and acceptance is a mark of approval for a protocol. Thus we should limit BIP assignment to the minimum possible: _extremely_ widespread standards used by the _entire_ Bitcoin community, for the core mission of Bitcoin. This would eliminate most wallet-related protocols e.g. BIP69 (sorted keys), ypubs, zpubs, etc. I don't particularly like any of those but if they can't be BIPs then they'd need to find another spec repository where they wouldn't be lost and where updates could be tracked. The SLIP repo could serve this purpose, and I think e.g. SLIP39 is not a BIP in part because of perceived friction and exclusivity of the BIPs repo. But I'm not thrilled with this situation. In fact, I would prefer that OpenTimestamps were a BIP :). It's notable that Lightning is _not_ standardized via the BIP process. I think that's a good thing. While it's arguably of wide enough use to warrent BIPs, Lightning doesn't need the approval of Core maintainers, and using their separate BOLT process makes that clear. Well, LN is a bit special because it's so big that it can have its own spec repo which is actively maintained and used. While it's technically true that BIPs need "approval of Core maintainers" to be merged, the text of BIP2 suggests that this approval should be a functionary role and be pretty-much automatic. And not require the BIP be relevant or interesting or desireable to Core developers. ___ 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] Ordinals BIP PR
On Mon, Oct 23, 2023 at 03:35:30PM +, Peter Todd via bitcoin-dev wrote: > > I have _not_ requested a BIP for OpenTimestamps, even though it is of much > wider relevance to Bitcoin users than Ordinals by virtue of the fact that much > of the commonly used software, including Bitcoin Core, is timestamped with > OTS. > I have not, because there is no need to document every single little protocol > that happens to use Bitcoin with a BIP. > > Frankly we've been using BIPs for too many things. There is no avoiding the > act > that BIP assignment and acceptance is a mark of approval for a protocol. Thus > we should limit BIP assignment to the minimum possible: _extremely_ widespread > standards used by the _entire_ Bitcoin community, for the core mission of > Bitcoin. > This would eliminate most wallet-related protocols e.g. BIP69 (sorted keys), ypubs, zpubs, etc. I don't particularly like any of those but if they can't be BIPs then they'd need to find another spec repository where they wouldn't be lost and where updates could be tracked. The SLIP repo could serve this purpose, and I think e.g. SLIP39 is not a BIP in part because of perceived friction and exclusivity of the BIPs repo. But I'm not thrilled with this situation. In fact, I would prefer that OpenTimestamps were a BIP :). > It's notable that Lightning is _not_ standardized via the BIP process. I think > that's a good thing. While it's arguably of wide enough use to warrent BIPs, > Lightning doesn't need the approval of Core maintainers, and using their > separate BOLT process makes that clear. > Well, LN is a bit special because it's so big that it can have its own spec repo which is actively maintained and used. While it's technically true that BIPs need "approval of Core maintainers" to be merged, the text of BIP2 suggests that this approval should be a functionary role and be pretty-much automatic. And not require the BIP be relevant or interesting or desireable to Core developers. -- 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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinals BIP PR
On Mon, 2023-10-23 at 15:35 +, Peter Todd via bitcoin-dev wrote: > Thus > we should limit BIP assignment to the minimum possible: _extremely_ > widespread > standards used by the _entire_ Bitcoin community, for the core > mission of > Bitcoin. BIPs are Bitcoin Improvement *Proposals*. What you suggest would imply that someone needs to evaluate them even before they become proposals. And this raises plenty of notoriously hard to answers questions: * Who is in charge? * How to predict if a proposal will be a widespread standard? * What is the core mission of Bitcoin? * How to measure if something is for the core mission? * Who and what is the _entire_ Bitcoin community? Best, Tim ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinals BIP PR
BIPs such as the increase in block size, drives-chains, colored coins, etc... were proposals for Bitcoin improvements. On the other hand, your BIP brings absolutely no improvement, on the contrary it is a regression, but you already know that. I strongly invite you to retract or if the desire continues to push you to negatively affect the chain, to create OIPs or anything similar, as far as possible from the development of Bitcoin and real BIPs that improve Bitcoin. Léo Haf. > Le 23 oct. 2023 à 10:23, Casey Rodarmor via bitcoin-dev > a écrit : > > Dear List, > > The Ordinals BIP PR has been sitting open for nine months now[0]. I've > commented a few times asking the BIP editors to let me know what is needed > for the BIP to either be merged or rejected. I've also reached out to the BIP > editors via DM and email, but haven't received a response. > > There has been much misunderstanding of the nature of the BIP process. BIPS, > in particular informational BIPs, are a form of technical documentation, and > their acceptance does not indicate that they will be included in any > implementation, including Bitcoin Core, nor that they they have consensus > among the community. > > Preexisting BIPs include hard-fork block size increases, hard-fork > proof-of-work changes, colored coin voting protocols, rejected soft fork > proposals, encouragement of address reuse, and drivechain. > > I believe ordinals is in-scope for a BIP, and am hoping to get the PR > unstuck. I would appreciate feedback from the BIP editors on whether it is > in-scope for a BIP, if not, why not, and if so, what changes need to be made > for it to be accepted. > > Best regards, > Casey Rodarmor > > [0] https://github.com/bitcoin/bips/pull/1408 > ___ > 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] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
On 10/20/23 7:43 PM, Peter Todd wrote: On Fri, Oct 20, 2023 at 09:55:12PM -0400, Matt Corallo wrote: Quite the contrary. Schnorr signatures are 64 bytes, so in situations like lightning where the transaction form is deterministically derived, signing 100 extra transactions requires just 6400 extra bytes. Even a very slow 100KB/s connection can transfer that in 64ms; latency will still dominate. Lightning today isn't all that much data, but multiply it by 100 and we start racking up data enough that people may start to have to store a really material amount of data for larger nodes and dealing with that starts to be a much bigger pain then when we're talking about a GiB or twenty. We are talking about storing ephemeral data here, HTLC transactions and possibly commitment transactions. Since lightning uses disclosed secrets to invalidate old state, you do not need to keep every signature from your counterparty indefinitely. Mmm, fair point, yes. RBF has a minimum incremental relay fee of 1sat/vByte by default. So if you use those 100 pre-signed transaction variants to do nothing more than sign every possible minimum incremental relay, you've covered a range of 1sat/vByte to 100sat/vByte. I believe that is sufficient to get mined for any block in Bitcoin's entire modern history. CPFP meanwhile requires two transactions, and thus extra bytes. Other than edge cases with very large transactions in low-fee environments, there's no circumstance where CPFP beats RBF. What I was referring to is that if we have the SIGHASH_SINGLE|ANYONECANPAY we can combine many HTLC claims into one transaction, vs pre-signing means we're stuck with a ton of individual transactions. Since SIGHASH_SINGLE requires one output per input, the savings you get by combining multiple SIGHASH_SINGLE transactions together aren't very significant. Just 18 bytes for nVersion, nLockTime, and the txin and txout size fields. The HTLC-timeout transaction is 166.5 vBytes, so that's a savings of just 11% Yep, its not a lot, but for a thing that's inherently super chain-spammy, its still quite nice. Of course, if you _do_ need to fee bump and add an additional input, that input takes up space, and you'll probably need a change output. At which point you again would probably have been better off with a pre-signed transaction. You are also assuming there's lots of HTLC's in flight that need to be spent. That's very often not the case. In general, yes, in force-close cases often there's been some failure which is repeated in several HTLCs :). More generally, I think we're getting lost here - this isn't really a material change for lightning's trust model - its already the case that a peer that is willing to put a lot of work in can probably steal your money, and there's now just one more way they can do that. We really don't need to rush to "fix lightning" here, we can do it right and fix it at the ecosystem level. It shouldn't be the case that a policy restriction results in both screwing up a L2 network *and* results in miners getting paid less. That's a policy bug. Matt ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Lightning-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
On Mon, Oct 23, 2023 at 11:10:56AM +, ZmnSCPxj wrote: > Hi all, > > This was discussed partially on the platform formerly known as twitter, but > an alternate design goes like this: > > * Add an `nExpiryTime` field in taproot annex. I would strongly suggest making it nExpiryHeight, and only offering the option of expiration at a given height. Time-based anything is sketchy, as it could give miners incentives to lie about the current time in the nTime field. If anything, the fact that nLockTime can in fact be time-based was a design mistake. > * This indicates that the transaction MUST NOT exist in a block at or above > the height specified. > * Mempool should put txes buckets based on `nExpiryTime`, and if the block > is reached, drop all the buckets with `nExpiryTime` less than that block > height. > * Add an `OP_CHECKEXPIRYTIMEVERIFY` opcode, mostly similar in behavior to > `OP_EXPIRE` proposed by Peter Todd: Note that if we redefine an OP_SuccessX opcode, we do not need _Verify behavior. We can produce a true/false stack element, making either OP_Expire or OP_CheckExpiryTime better names for the opcode. > * Check if `nExpiryTime` exists and has value equal or less than the stack > top. > > The primary difference is simply that while Peter proposes an implicit field > for the value that `OP_EXPIRE` will put in `CTransaction`, I propose an > explicit field for it in the taproot annex. To be clear, I also proposed an explicit field too. But I had a brainfart and forgot that we'd added the taproot annex. So I proposed re-using part of nVersion. > The hope is that "explicit is better than implicit" and that the design will > be better implemented as well by non-Bitcoin-core implementations, as the use > of tx buckets is now explicit in treating the `nExpiryTime` field. Also, having a nExpiryHeight may be useful in cases where a signature covering the field is sufficient. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinals BIP PR
On Fri, Oct 20, 2023 at 10:38:01PM -0700, Casey Rodarmor via bitcoin-dev wrote: > Dear List, > > The Ordinals BIP PR has been sitting open for nine months now[0]. I've > commented a few times asking the BIP editors to let me know what is needed > for the BIP to either be merged or rejected. I've also reached out to the > BIP editors via DM and email, but haven't received a response. > > There has been much misunderstanding of the nature of the BIP process. > BIPS, in particular informational BIPs, are a form of technical > documentation, and their acceptance does not indicate that they will be > included in any implementation, including Bitcoin Core, nor that they they > have consensus among the community. > > Preexisting BIPs include hard-fork block size increases, hard-fork > proof-of-work changes, colored coin voting protocols, rejected soft fork > proposals, encouragement of address reuse, and drivechain. I have _not_ requested a BIP for OpenTimestamps, even though it is of much wider relevance to Bitcoin users than Ordinals by virtue of the fact that much of the commonly used software, including Bitcoin Core, is timestamped with OTS. I have not, because there is no need to document every single little protocol that happens to use Bitcoin with a BIP. Frankly we've been using BIPs for too many things. There is no avoiding the act that BIP assignment and acceptance is a mark of approval for a protocol. Thus we should limit BIP assignment to the minimum possible: _extremely_ widespread standards used by the _entire_ Bitcoin community, for the core mission of Bitcoin. It's notable that Lightning is _not_ standardized via the BIP process. I think that's a good thing. While it's arguably of wide enough use to warrent BIPs, Lightning doesn't need the approval of Core maintainers, and using their separate BOLT process makes that clear. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinals BIP PR
On Fri, Oct 20, 2023 at 10:38:01PM -0700, Casey Rodarmor via bitcoin-dev wrote: > > > > There has been much misunderstanding of the nature of the BIP process. > BIPS, in particular informational BIPs, are a form of technical > documentation, and their acceptance does not indicate that they will be > included in any implementation, including Bitcoin Core, nor that they they > have consensus among the community. > > Preexisting BIPs include hard-fork block size increases, hard-fork > proof-of-work changes, colored coin voting protocols, rejected soft fork > proposals, encouragement of address reuse, and drivechain. > > > I agree and I think it sets a bad precedent to be evaluating BIPs based on the merits of their implementation (vs their specification) or their consequences for the network. Actual consensus is much bigger than the BIPs repo, so this accomplishes little beyond making the BIPs repo itself hard to interact with. In the worst case it may cause people to interpret BIP numbers as indicating that proposals are "blessed" by some particular influential set of people, which can only cause problems. -- 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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposed BIP for OP_CAT
On Mon, Oct 23, 2023 at 12:43:10PM +1030, Rusty Russell via bitcoin-dev wrote: > Ethan Heilman via bitcoin-dev writes: > > Hi everyone, > > > > We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode. > > https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki > > This is really nice to see! > > AFAICT you don't define the order of concatenation, except in the > implementation[1]. I think if A is top of stack, we get BA, not AB? > > 520 feels quite small for script templates (mainly because OP_CAT itself > makes Script more interesting!). For example, using OP_TXHASH and > OP_CAT to enforce that two input amounts are equal to one output amount > takes about 250 bytes of Script[2] :( > > So I have to ask: > > 1. Do other uses feel like 520 is too limiting? In my view, 520 feels limiting provided that we lack rolling sha2 opcodes. If we had those, then arguably 65 bytes is enough. Without them, I'm not sure that any value is "enough". For CHECKSIGFROMSTACK emulation purposes ideally we'd want the ability to construct a full transaction on the stack, which in principle would necessitate a 4M limit. > 2. Was there a concrete rationale for maintaining 520 bytes? 10k is the > current >script limit, can we get closer to that? :) But as others have said, 520 bytes is the existing stack element limit and minimizing changes seems like a good strategy to get consensus. (On the other hand, it's been a few days without any opposition so maybe we should be more agressive :)). > 3. Should we restrict elsewhere instead? After all, OP_CAT doesn't >change total stack size, which is arguably the real limit? > Interesting thought. Right now the stack size is limited to 1000 elements of 520 bytes each, which theoretically means a limit of 520k. Bitcoin Core doesn't explicitly count the "total stack size" in the sense that you're suggesting; it just enforces these two limits separately. I think trying to add a "total stack size limit" (which would have to live alongside the two existing limits; we can't replace them without a whole new Tapscript version) would add a fair bit of accounting complextiy and wind up touching almost every other opcode...probably not worth the added consensus logic. > Of course, we can increase this limit in future tapscript versions, too, > so it's not completely set in stone. > -- 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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposed BIP for OP_CAT
On Mon, Oct 23, 2023 at 12:43:10PM +1030, Rusty Russell via bitcoin-dev wrote:
> 2. Was there a concrete rationale for maintaining 520 bytes?
Without a limit of 520 bytes, then you can construct a script:
CHECKSIGVERIFY
{DUP CAT}x10
(we know have a string that is the second witness repeated 1024 times
on the stack; if it was 9 bytes, call it 9216B total)
{DUP} x 990
(we now have 1000 strings each of length 9216B bytes, for ~9.2MB total)
SHA256SUM {CAT SHA256SUM}x999
(we now have a single 32B field on the stack)
EQUAL
(and can do a hardcoded check to make sure there weren't any
shortcuts taken)
That raises the max memory to verify a single script from ~520kB (1000
stack elements by 520 bytes each) to ~10MB (1000 stack elements by
10kB each).
> 10k is the current script limit, can we get closer to that? :)
The 10k limit applies to scriptPubKey, scriptSig and segwit v0 scripts.
There's plenty of examples of larger tapscripts, eg:
https://mempool.space/tx/0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae
(3,938,182 bytes of script, non-standard due to being an oversized tx)
https://mempool.space/tx/2d4ad78073f1187c689c693bde62094abe6992193795f838e8be0db898800434
(360,543 bytes of script, standard, I believe)
Cheers,
aj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Lightning-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
Hi all, This was discussed partially on the platform formerly known as twitter, but an alternate design goes like this: * Add an `nExpiryTime` field in taproot annex. * This indicates that the transaction MUST NOT exist in a block at or above the height specified. * Mempool should put txes buckets based on `nExpiryTime`, and if the block is reached, drop all the buckets with `nExpiryTime` less than that block height. * Add an `OP_CHECKEXPIRYTIMEVERIFY` opcode, mostly similar in behavior to `OP_EXPIRE` proposed by Peter Todd: * Check if `nExpiryTime` exists and has value equal or less than the stack top. The primary difference is simply that while Peter proposes an implicit field for the value that `OP_EXPIRE` will put in `CTransaction`, I propose an explicit field for it in the taproot annex. The hope is that "explicit is better than implicit" and that the design will be better implemented as well by non-Bitcoin-core implementations, as the use of tx buckets is now explicit in treating the `nExpiryTime` field. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
On 2023-10-21 18:49, Nadav Ivgi via bitcoin-dev wrote: Could this be addressed with an OP_CSV_ALLINPUTS, a covenant opcode that requires _all_ inputs to have a matching nSequence, and using `1 OP_CSV_ALLINPUTS` in the HTLC preimage branch? This would prevent using unconfirmed outputs in the HTLC-preimage-spending transaction entirely, which IIUC should protect it against the replacement cycling attack. I don't think that addresses the underlying problem. In Riard's description, a replacement cycle looks like this: - Bob broadcasts an HTLC-timeout (input A, input B for fees, output X) - Mallory replaces the HTLC-timeout with an HTLC-preimage (input A, input C for fees, output Y) - Mallory replaces the transaction that created input C, removing the HTLC-preimage from the mempool However, an alternative approach is: - (Same) Bob broadcasts an HTLC-timeout (input A, input B for fees, output X) - (Same) Mallory replaces the HTLC-timeout with an HTLC-preimage (input A, input C for fees, output Y) - (Different) Mallory uses input C to replace the HTLC-preimage with a transaction that does not include input A, removing the preimage from the mempool The original scenario requires input C to be from an unconfirmed transaction, so OP_CSV_ALLINPUTS works. The alternative scenario works even if input C comes from a confirmed transaction, so OP_CSV_ALLINPUTS is ineffective. -Dave ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposed BIP for OP_CAT
> I think if A is top of stack, we get BA, not AB? Good question. I always thought "0x01234567 0x89abcdef OP_CAT 0x0123456789abcdef OP_EQUAL" is correct, but it could be reversed as well. If we want to stay backward-compatible, we can dig into the past, and test the old implementation of OP_CAT, before it was disabled. But anyway, any of those two choices will lead to similar consequences. Because you can always turn the former into the latter by using "OP_SWAP OP_CAT", instead of "OP_CAT". > 520 feels quite small for script templates It will be easier to start with that, when it comes to reaching consensus for a new soft-fork. But yes, I am very surprised, because I thought we will never see things like that, and I assumed the path to OP_CAT is just permanently closed. So, I am surprised this BIP reached a positive reaction, but well, that kind of proposal was not battle-tested, so maybe it could succeed. > 10k is the current script limit, can we get closer to that? We will get there anyway. Even if OP_CAT would allow concatenating up to 520-bit Schnorr signature (not to confuse 520-bit with 520-byte), people would chain it, to reach arbitrary size. If you can concatenate secp256k1 public keys with signatures, you can create a chain of OP_CATs, that will handle arbitrary size. The only limitation is then blockchain speed, which is something around 4 MB/10 min, and that is your only limit in this case. And yes, if I can see that some people try to build logical gates like NAND with Bitcoin Script, then I guess all paths will be explored anyway. Which means, even if we will take more conservative approach, and switch from 520-byte proposal into 520-bit proposal, then still, people will do exactly the same things. Now, it is all about the cost of pushing data, because some people noticed, that everything can be executed on Script. I knew we will get there, but I expected it would just happen later than it happened. > Of course, we can increase this limit in future tapscript versions, too, so > it's not completely set in stone. Judging by the last misuse of Ordinals, I think it may happen before anyone will propose some official future version. Which means, nothing is really set in stone anymore, because now people know, how to activate new features, without any soft-fork, and some no-forks will probably be done by newbies, without careful designing and testing, as it is done here.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Ordinals BIP PR
Dear List, The Ordinals BIP PR has been sitting open for nine months now[0]. I've commented a few times asking the BIP editors to let me know what is needed for the BIP to either be merged or rejected. I've also reached out to the BIP editors via DM and email, but haven't received a response. There has been much misunderstanding of the nature of the BIP process. BIPS, in particular informational BIPs, are a form of technical documentation, and their acceptance does not indicate that they will be included in any implementation, including Bitcoin Core, nor that they they have consensus among the community. Preexisting BIPs include hard-fork block size increases, hard-fork proof-of-work changes, colored coin voting protocols, rejected soft fork proposals, encouragement of address reuse, and drivechain. I believe ordinals is in-scope for a BIP, and am hoping to get the PR unstuck. I would appreciate feedback from the BIP editors on whether it is in-scope for a BIP, if not, why not, and if so, what changes need to be made for it to be accepted. Best regards, Casey Rodarmor [0] https://github.com/bitcoin/bips/pull/1408 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
