* [bitcoindev] Covenants Support - Bitcoin Wiki @ 2024-11-29 14:08 /dev /fd0 2024-12-06 21:45 ` Jonas Nick 0 siblings, 1 reply; 8+ messages in thread From: /dev /fd0 @ 2024-11-29 14:08 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 1292 bytes --] Hi Bitcoin Developers, I have created the first draft of a bitcoin wiki page to update opinions of bitcoin developers on different covenant proposals. It uses the same template as segwit support page. Feel free to add more opcodes as I only added the ones that looked relevant. Wiki link: https://en.bitcoin.it/wiki/Covenants_support I am aware of the opinions of some developers; however, I did not want to write on their behalf. Please add your GitHub username and share your opinions on the proposed opcodes. This would help in reaching a consensus on the next soft fork and make things easier. Rationale for supporting OP_CTV: https://notes.dunst.be/slide/#/2/slide/view/Ekky-cAegV9dSOaNOjH9TStNOmAnrhDDc9hxHlmRs5M/embed/present/ I like a few other use cases however mainly interested in pools with covenants. This would help improve joinstr (coinjoin implementation). /dev/fd0 floppy disk guy -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/028c0197-5c45-4929-83a9-cfe7c87d17f4n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 1859 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoindev] Covenants Support - Bitcoin Wiki 2024-11-29 14:08 [bitcoindev] Covenants Support - Bitcoin Wiki /dev /fd0 @ 2024-12-06 21:45 ` Jonas Nick 2024-12-07 0:29 ` /dev /fd0 2024-12-09 20:13 ` Anthony Towns 0 siblings, 2 replies; 8+ messages in thread From: Jonas Nick @ 2024-12-06 21:45 UTC (permalink / raw) To: bitcoindev Hi /dev/fd0, I do not think the segwit support page serves as a suitable template for building rough consensus, in general and for covenants in particular. It lacks key characteristics that would help in (rough) consensus building as outlined in RFC 7282 [0] (which I strongly recommend reading). I propose the following changes: 1. Separate Technical Evaluation from Community Support The ratings "Deficient" and "Wanting" are supposed to be assigned when a proposal considered to have insufficient community support. This creates a circular problem: the wiki page is meant to help build community support, but the ratings already assume certain levels of support. This makes the ratings less useful and risks creating self-fulfilling prophecies. A simple solution would be to remove the "Wanting" and "Deficient" categories. 2. Require Stating Reasons for Objections As RFC 7282 states: > Remember, coming to consensus is a matter of eliminating disagreement. To achieve this, we need to clearly state objections to enable a meaningful discussion. Each "No" rating should include a link to a mailing list post or similar document that explicitly states the objection, covering aspects such as technical deficiencies, likelihood of widespread adoption, and impact on decentralization. > Then, the purported failings > of the choice can be examined by the working group. The objector > might convince the rest of the group that the objections are valid > and the working group might choose a different path. Conversely, the > working group might convince the objector that the concerns can be > addressed, or that the choice is simply unappealing (i.e., something > the objector can "live with") and not a show-stopper. Because there is no working group making decisions in Bitcoin, community members must individually assess whether proposals have achieved rough developer consensus. Developers giving positive technical evaluations are also encouraged to share their reasoning, as this can help inform others' assessments. 3. Add Links to BIP Drafts All opcodes mentioned on the wiki page presumably have corresponding draft BIPs. These should be linked to provide a clear basis for technical evaluation. [0] https://datatracker.ietf.org/doc/html/rfc7282 -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/941b8c22-0b2c-4734-af87-00f034d79e2e%40gmail.com. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoindev] Covenants Support - Bitcoin Wiki 2024-12-06 21:45 ` Jonas Nick @ 2024-12-07 0:29 ` /dev /fd0 2024-12-07 1:42 ` Yuval Kogman 2024-12-09 20:13 ` Anthony Towns 1 sibling, 1 reply; 8+ messages in thread From: /dev /fd0 @ 2024-12-07 0:29 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 4479 bytes --] Hi Jonas, Thank you for reviewing the wiki page. > 1. Separate Technical Evaluation from Community Support > A simple solution would be to remove the "Wanting" and "Deficient" categories. There are 7 options available to share opinion on an opcode and only 2 include community support. If a developer wants to ACK a proposal it is possible to use to 'prefer' or 'acceptable' and 'no' for NACK. We have already changed definition for 3 categories. I removed community support from 'no' and moonsettler rephrased 'prefer' and 'evaluating'. Removing some categories at this point breaks the whole table. At the end of the day bitcoin developers build for community so if someone wants to play safe and use 'deficient' and 'wanting', its their choice and I think we should allow such freedom to express themselves. > 2. Require Stating Reasons for Objections A column for adding a link to rationale will be added this weekend. I had tweeted about it but forgot to update the mailing list thread. > Because there is no working group making decisions in Bitcoin, > community members must individually assess whether proposals have achieved > rough developer consensus. > Developers giving positive technical evaluations are also encouraged to share > their reasoning, as this can help inform others' assessments. I agree with you on this and I have requested everyone to respond to this thread. > 3. Add Links to BIP Drafts I have added the links to BIP drafts for all opcodes. /dev/fd0 floppy disk guy On Saturday, December 7, 2024 at 4:18:21 AM UTC+5:30 Jonas Nick wrote: > Hi /dev/fd0, > > I do not think the segwit support page serves as a suitable template for > building rough consensus, in general and for covenants in particular. It > lacks > key characteristics that would help in (rough) consensus building as > outlined in > RFC 7282 [0] (which I strongly recommend reading). > > I propose the following changes: > > 1. Separate Technical Evaluation from Community Support > > The ratings "Deficient" and "Wanting" are supposed to be assigned when a > proposal considered to have insufficient community support. This creates a > circular problem: the wiki page is meant to help build community support, > but > the ratings already assume certain levels of support. This makes the > ratings > less useful and risks creating self-fulfilling prophecies. > > A simple solution would be to remove the "Wanting" and "Deficient" > categories. > > 2. Require Stating Reasons for Objections > > As RFC 7282 states: > > > Remember, coming to consensus is a matter of eliminating disagreement. > > To achieve this, we need to clearly state objections to enable a meaningful > discussion. Each "No" rating should include a link to a mailing list post > or > similar document that explicitly states the objection, covering aspects > such > as technical deficiencies, likelihood of widespread adoption, and impact on > decentralization. > > > Then, the purported failings > > of the choice can be examined by the working group. The objector > > might convince the rest of the group that the objections are valid > > and the working group might choose a different path. Conversely, the > > working group might convince the objector that the concerns can be > > addressed, or that the choice is simply unappealing (i.e., something > > the objector can "live with") and not a show-stopper. > > Because there is no working group making decisions in Bitcoin, > community members must individually assess whether proposals have achieved > rough developer consensus. > > Developers giving positive technical evaluations are also encouraged to > share > their reasoning, as this can help inform others' assessments. > > 3. Add Links to BIP Drafts > > All opcodes mentioned on the wiki page presumably have corresponding draft > BIPs. These should be linked to provide a clear basis for technical > evaluation. > > [0] https://datatracker.ietf.org/doc/html/rfc7282 > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/6d375199-834e-4630-8b5c-fcc5ed137cb1n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 5731 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoindev] Covenants Support - Bitcoin Wiki 2024-12-07 0:29 ` /dev /fd0 @ 2024-12-07 1:42 ` Yuval Kogman 0 siblings, 0 replies; 8+ messages in thread From: Yuval Kogman @ 2024-12-07 1:42 UTC (permalink / raw) To: /dev /fd0; +Cc: Bitcoin Development Mailing List On Sat, 7 Dec 2024 at 02:10, /dev /fd0 <alicexbtong@gmail•com> wrote: > > There are 7 options available to share opinion on an opcode and only 2 include community support. If a developer wants to ACK a proposal it is possible to use to 'prefer' or 'acceptable' and 'no' for NACK. the 6 options (+ "evaluating", which is not in the space) represent only a subset of the product of two independent dimensions: - a given dev's (hopefully reasoned) opinion on the technical merit of a proposal - and their (speculative, vibes based) opinion about community support. > At the end of the day bitcoin developers build for community so if someone wants to play safe and use 'deficient' and 'wanting', its their choice and I think we should allow such freedom to express themselves. to allow that full freedom to express themselves 8 options seem necessary, not counting "evaluating": { no, weak, acceptable, prefer } x { sufficient community support, insufficient } (or alternatively, { no, weak, acceptable } is the technical merit dimension, and then "prefer" seems redundant?) anyway, supposing all pairs of values were expressible, the latter is confounded or arguably even ill defined see https://en.wikipedia.org/wiki/Keynesian_beauty_contest (and this is exacerbated by the fact that the two values are combined into a single dimension, e.g. if i strongly prefer something but it lacks community support), so to allow people to e.g. only express a technical opinion, and abstain from speculating on community support, we'd want: { ⊥, weak, acceptable, prefer } x { ⊥, sufficient, insufficient } (where evaluating = (⊥, ⊥)) finally, even if the full set of possibilities was expressible, and assuming the infinite regress of speculating on others' opinions about others opinions was not an issue, it would still not be totally orderable, so the color scheme is arguably misleading both the partial ordering and the speculative nature add a lot of ambiguity, i.e. different answers are likely to mean different things to different respondents and to people reading the table -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAQdECALHHysr4PNRGXcFMCk5AjRDYgquUUUvuvwHGoeJDgZJA%40mail.gmail.com. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoindev] Covenants Support - Bitcoin Wiki 2024-12-06 21:45 ` Jonas Nick 2024-12-07 0:29 ` /dev /fd0 @ 2024-12-09 20:13 ` Anthony Towns 2024-12-09 20:45 ` Brandon Black 1 sibling, 1 reply; 8+ messages in thread From: Anthony Towns @ 2024-12-09 20:13 UTC (permalink / raw) To: Jonas Nick; +Cc: bitcoindev On Fri, Dec 06, 2024 at 09:45:31PM +0000, Jonas Nick wrote: > I do not think the segwit support page serves as a suitable template for > building rough consensus, in general and for covenants in particular. The segwit page followed the example of the p2sh page [0]; I wasn't around for that, but from the reporting it didn't sound like a particularly clean result, with the result coming down to the proposers of BIP 16/17 respectively voting "No" and "Very weak" to the competition, and "No" being worse than "Very weak". It's not a good example to follow. [0] https://en.bitcoin.it/wiki/P2SH_Votes The only polling question that's really necessary for establishing that consensus exists is "have all my objections/concerns been addressed? [yes/no]" (perhaps with a followup asking your top outstanding concerns are). If the poll is widely open, and everyone's answer is "yes"; that's consensus. (Even if some people's answers are "no"; it might still be "rough" consensus, of course) Personally, I find it hard to take any of this remotely seriously at this point; the most recent example is reardencode's claim to have created scripts for lightning-symmetry using either LNHANCE or CCV. This was done via a tweet [1] and a gist [2], without any real exploration of what the full transaction flow would look like. Did it have any chance of working? Well, no, because it had an invented "3DROP" opcode instead of "DROP 2DROP" or similar, just as if it were ChatGPT hallucinating what a wallet script might look like. That would have failed as soon as it had been run through any of the script test environments out there, let alone through any actual node software, so it's clear that nobody involved had done anything of the sort, even locally. If the proponents aren't taking their proposals seriously, why on earth should anyone else? [1] https://x.com/reardencode/status/1864749512113483993 [2] https://gist.github.com/reardencode/ae982ede45af12fe1ff7248fd6f1958c#file-ctv-csfs-vault-txt Cheers, aj -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z1dPfjDwioa/DXzp%40erisian.com.au. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoindev] Covenants Support - Bitcoin Wiki 2024-12-09 20:13 ` Anthony Towns @ 2024-12-09 20:45 ` Brandon Black 2024-12-11 13:28 ` Anthony Towns 0 siblings, 1 reply; 8+ messages in thread From: Brandon Black @ 2024-12-09 20:45 UTC (permalink / raw) To: Anthony Towns; +Cc: Jonas Nick, bitcoindev Hi AJ, On 2024-12-10 (Tue) at 06:13:50 +1000, Anthony Towns wrote: > Personally, I find it hard to take any of this remotely seriously at this > point; the most recent example is reardencode's claim to have created > scripts for lightning-symmetry using either LNHANCE or CCV. This was > done via a tweet [1] and a gist [2], without any real exploration of > what the full transaction flow would look like. Did it have any chance of > working? Well, no, because it had an invented "3DROP" opcode instead of > "DROP 2DROP" or similar, just as if it were ChatGPT hallucinating what > a wallet script might look like. That would have failed as soon as it > had been run through any of the script test environments out there, > let alone through any actual node software, so it's clear that nobody > involved had done anything of the sort, even locally. If the proponents > aren't taking their proposals seriously, why on earth should anyone else? > > [1] https://x.com/reardencode/status/1864749512113483993 > [2] https://gist.github.com/reardencode/ae982ede45af12fe1ff7248fd6f1958c#file-ctv-csfs-vault-txt You've made two strange errors in your commentary here. First, my example scripts for Lightning Symmetry all use opcodes that do not exist in the script testing environments so I cannot run my scripts through those environments. The point of the exercise is to demonstrate how the potential opcodes can perform an example protocol and roughly how the cost compares. The fact that I misglanced the opcode list during drafting is completely irrelevant to the exercise. Second, I am not a "proponent" of VAULT or CCV. I'm merely demonstrating various ways that they can be used, as a service to those who are discussing various options for upgrading bitcoin (as I strongly implied in my post on X - I only wrote the script you found an error in because of others' answers on Floppy's table). In other words, it's hard to take your commentary seriously when you don't bother to understand either the purpose and the context of what you are commenting on. Hope this clarifies. All the best, --Brandon -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z1dW77h3rhr5oivP%40console. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoindev] Covenants Support - Bitcoin Wiki 2024-12-09 20:45 ` Brandon Black @ 2024-12-11 13:28 ` Anthony Towns 2024-12-11 15:11 ` Brandon Black 0 siblings, 1 reply; 8+ messages in thread From: Anthony Towns @ 2024-12-11 13:28 UTC (permalink / raw) To: Brandon Black; +Cc: bitcoindev On Mon, Dec 09, 2024 at 12:45:35PM -0800, Brandon Black wrote: > First, my example scripts for Lightning Symmetry all use opcodes that do > not exist in the script testing environments so I cannot run my scripts > through those environments. You've implemented your code against bitcoin inquisition 27.x [0], which already includes an "evalscript" subcommand [1] that allows you to do precisely that, even without updating the functional test suite so that CI passes. So, yes, you can run your scripts through testing environments. You can also easily tweak your scripts to run them through unmodified testing environments to at least ensure you aren't making trivial errors and to check the stack is working the way you think it should -- replace the new commands with OP_NOP (for things like CTV) or OP_2DROP OP_VERIFY (for things like CHECKSIGVERIFY, where an empty signature would fail, and there are two other arguments to ignore). > The fact that I misglanced the opcode list > during drafting is completely irrelevant to the exercise. That you made a mistake is perhaps excusable, though as someone proposing to modify the script language, being more than glancingly familiar with script as it is today seems like a pretty basic expectation. That you didn't put your work through even the most basic testing cycle before publicising it isn't so excusable. [2] It's utterly astounding to me that you're publicising your project as "lnhance" [3] and yet are willing to be that careless in your demonstrations of how it might enhance the lightning network. Cheers, aj [0] https://github.com/bitcoin-inquisition/bitcoin/pull/45 [1] https://github.com/bitcoin-inquisition/bitcoin/pull/58 [2] For instance, I made a claim above that you can use evalscript with your inquisition pr. That's something that I should test, and when I do, it turns out there's a line that needs fixing to make that work. Here's what it looks like after that's done, checking the first entry in the bip340 test vectors: ``` $ ./bitcoin-util -sigversion=tapscript -script_flags=CHECKSIGFROMSTACK evalscript '0x200000000000000000000000000000000000000000000000000000000000000000 0x20F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9 CHECKSIGFROMSTACK' E907831F80848D1069A5371B402410364BDF1C5F8307B0084C55F1CE2DCA821525F66A4A85EA8B71E482A74F382D2CE5EBEEE8FDB2172F477DF4900D310536C0 { "script": { "asm": "0000000000000000000000000000000000000000000000000000000000000000 f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9 OP_CHECKSIGFROMSTACK", "hex": "20000000000000000000000000000000000000000000000000000000000000000020f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9cc", "type": "nonstandard" }, "sigversion": "tapscript", "script_flags": [ "CHECKSIGFROMSTACK" ], "stack-after": [ "01" ], "sigop-count": 0, "success": true } ``` [3] https://www.lnhance.org/#team -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z1mTiguyy5waz4Vg%40erisian.com.au. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoindev] Covenants Support - Bitcoin Wiki 2024-12-11 13:28 ` Anthony Towns @ 2024-12-11 15:11 ` Brandon Black 0 siblings, 0 replies; 8+ messages in thread From: Brandon Black @ 2024-12-11 15:11 UTC (permalink / raw) To: Anthony Towns; +Cc: bitcoindev Hi AJ, On 2024-12-11 (Wed) at 23:28:42 +1000, Anthony Towns wrote: > On Mon, Dec 09, 2024 at 12:45:35PM -0800, Brandon Black wrote: > > First, my example scripts for Lightning Symmetry all use opcodes that do > > not exist in the script testing environments so I cannot run my scripts > > through those environments. > > You've implemented your code against bitcoin inquisition 27.x [0], > which already includes an "evalscript" subcommand [1] that allows you > to do precisely that, even without updating the functional test suite > so that CI passes. So, yes, you can run your scripts through testing > environments. There seems to still be some confusion here. The script you found a bug in was using OP_VAULT, which I haven't implemented and which is not in inquisition. > You can also easily tweak your scripts to run them through unmodified > testing environments to at least ensure you aren't making trivial errors > and to check the stack is working the way you think it should -- replace > the new commands with OP_NOP (for things like CTV) or OP_2DROP OP_VERIFY > (for things like CHECKSIGVERIFY, where an empty signature would fail, > and there are two other arguments to ignore). > > > The fact that I misglanced the opcode list > > during drafting is completely irrelevant to the exercise. > > That you made a mistake is perhaps excusable, though as someone proposing > to modify the script language, being more than glancingly familiar with > script as it is today seems like a pretty basic expectation. That you > didn't put your work through even the most basic testing cycle before > publicising it isn't so excusable. [2] I must have been unclear in how I published my recent script hacking to trigger this type of response. I did not say, "here are production ready scripts that I've validated for securing your funds." I hacked up a proof of concept to demonstrate conceptually how certain types of things can be done using certain proposed opcodes. Why would I have run them through a testing environment? Why would I have worried about whether there's 3DROP or only 3DUP? Those are irrelevant to whether CCV or VAULT can be used as part of a Lightning Symmetry implementation. Details that can be worked out later. I published my results and how I arrived at them (in the gist showing my expected stack progression) and anyone can correct me (as you did). > It's utterly astounding to me that you're publicising your project > as "lnhance" [3] and yet are willing to be that careless in your > demonstrations of how it might enhance the lightning network. My work on demonstrating how opcodes unrelated to LNHANCE can also be used for Lightning Symmetry is somehow related to my work on LNHANCE how? Did I do something to offend you? Best, --Brandon -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z1mrvy1wDcqxjXob%40console. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-12-11 15:22 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-11-29 14:08 [bitcoindev] Covenants Support - Bitcoin Wiki /dev /fd0 2024-12-06 21:45 ` Jonas Nick 2024-12-07 0:29 ` /dev /fd0 2024-12-07 1:42 ` Yuval Kogman 2024-12-09 20:13 ` Anthony Towns 2024-12-09 20:45 ` Brandon Black 2024-12-11 13:28 ` Anthony Towns 2024-12-11 15:11 ` Brandon Black
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox